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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the protocol details for voice call continuity between the IP Multimedia (IM) Core 
Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP) and 
the protocols of the 3GPP Circuit-Switched (CS) domain (CAP, MAP, ISUP, BICC and the NAS call control protocol 
for the CS access). 

Voice call continuity allows users to move between the CS domain and the IP Connectivity Access Network (e.g., 
WLAN interworking) with home IM CN subsystem functionality. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP, SIP Events and SDP, either directly, or as modified by 3GPP 
TS 24.229 [8]. Where this is not possible, extensions to SIP are defined within the present document. The document has 
therefore been structured in order to allow both forms of specification. 

Editor's note: If this TS makes no amendment to any of the IETF protocols, then this paragraph will not be included. 

The present document is applicable to User Equipment (UEs), Application Servers (AS) and Media Gateway Control 
Functions (MGCF) providing voice call continuity capabilities. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 22.101: "Service aspects; Service principles". 

[2] 3GPP TS 23.003: "Numbering, addressing and identification". 

[3] 3GPP TS 23.206: "Voice call continuity between Circuit Switched (CS) and IP Multimedia 

Subsystem (IMS); Stage 2". 

[4] 3GPP TS 23.228: "IP mulfimedia subsystem; Stage 2". 

[5] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[6] 3GPP TS 24.167: "3GPP IMS Management Object (MO); Stage 3". 

[7] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[8] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP". 

[9] 3GPP TS 29.078: "Customised Apphcations for Mobile network Enhanced Logic (CAMEL) Phase 

4; CAMEL Application Part (CAP) specification". 

[10] 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem 

and Circuit Switched (CS) networks". 

[II] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; SignaUing flows and message 
contents". 

[12] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 
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[13] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[14] ITU-T Recommendations Q.761to Q.764 (2000): "Specifications of Signalling System No.7 ISDN 

User Part (ISUP)". 

[15] ITU-T Recommendations Q.1902.1 to Q.1902.6 (07/2001): "Bearer Independent Call Control". 

[16] RFC 3264 (June 2002): "An Offer/Answer Model with Session Description Protocol (SDP)". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply. 

Retarget: A SIP request is retargeted when the original "target" indicated by the Request-URI is changed to 

a new "target" by changing the Request-URI. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [4] 
subclauses 5.4.12 apply: 

Public Service Identity (PSI) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [2] apply: 

CS Domain Routeing Number (CSRN) 
IP Multimedia Routeing Number (IMRN) 
Mobile Station Roaming Number (MSRN) 
VCC Domain Transfer Number (VDN) 
VCC Domain Transfer URI (VDI) 

For the purposes of the present document, the following terms and definitions given in ITU-T E.164 [13] apply: 

International public telecommunication number 
Public telecommunications number 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

BICC Bearer Independent Call Control 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CAP CAMEL Application Part 

CCCF Call Continuity Control Function 

CN Core Network 

CS Circuit Switched 

CSAF CS Adaptation Function 

CSCF Call Session Control Function 

CSRN CS Domain Routeing Number 

DSF Domain Selection Function 

DTF Domain Transfer Function 

EDGE Enhanced Data rates for GSM Evolution 

GERAN GSM EDGE Radio Access Network 

GMSC Gateway MSC 

GSM Global System for Mobile communications 

HLR Home Location Register 

HSS Home Subscriber Server 

IM IP Multimedia 

IP Internet Protocol 
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IMRN IP Multimedia Routeing Number 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

I-WLAN Interworking - WLAN 

MAP Mobile Application Part 

MS Mobile Station 

MSC Mobile Switching Centre 

MSISDN MS international PSTN/ISDN number 

MSRN Mobile Station Roaming Number 

NAS Non-Access Stratum 

PSI Public Service Identity 

PSTN Public Switched Telephone Network 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UE User Equipment 

URI Uniform Resource Identifier 

UTRAN Universal Terrestrial Radio Access Network 

VCC Voice Call Continuity 

VDI VCC Domain Transfer URI 

VDN VCC Domain Transfer Number 

VMSC Visited MSC 

WLAN Wireless Local Area Network 



Overview of voice call continuity between the Circuit- 
Switched (CS) domain and the IP Multimedia (IM) 
Core Network (CN) subsystem 



4.1 



General 



VCC allows a UE employing on the traditional CS domain accessed via either UTRAN or GERAN, and the IM CN 
subsystem accessed by a number of access technologies, e.g. I-WLAN, to have calls flexibly delivered over both the CS 
domain and the IM CN subsystem, and to pass the call from one to the other when access or other conditions alter. 

Voice calls originated by VCC subscribers in both the IM CN subsystem and in the CS domain are subject to anchoring 
in the IM CN subsystem. Similarly voice calls terminated to VCC subscribers are anchored in the IM CN subsystem. 
When anchoring occurs, such calls have a path to the VCC application from either the CS domain or the IM CN 
subsystem, so that the VCC application can be used to provide a domain transfer. If a call from a VCC subscriber is not 
anchored in the IM CN subsystem, domain transfer is not supported for that call. 

In order for the above to occur, the following procedures are supplied within this specification: 

procedures for call origination are specified in Clause 7. 

procedures for call termination are specified in Clause 8; 

procedures for transfer of a call from the CS domain to the IM CN subsystem are specified in Clause 9; 

procedures for transfer of a call from the IM CN subsystem to the CS domain are specified in Clause 10; and 



procedures for initialising a VCC application for a specific subscriber before the VCC UE makes or receives 
calls are specified in Clause 6. 

In this version of this document, VCC cannot be applied to emergency calls, and are not therefore anchored. 

4.2 Underlying network capabilities 

VCC assumes the use of a number of underlying network capabilities: 



£75/ 



3GPP TS 24.206 version 7.0.1 Release 7 9 ETSI TS 124 206 V7.0.1 (2007-10) 

1) provision by the home network operator of VCC specific AS on the IM CN subsystem, as specified in 

3GPPTS 24.229 [8]; 

2) signalUng within the CS domain (both within the home network and between the home network and any visited 
network) supported using either ISUP (as defined in ITU-T Recommendations Q.761 to Q.764 [14]) or BICC (as 
defined in ITU-T Recommendations Q.1902.1 to Q.1902.6 [15]); 

3) provision of CAMEL Phase 2 or later (as specified in 3GPP TS 29.078 [9]) at the VMSC; 

4) provision of CAMEL Phase 2 or later (as specified in 3GPP TS 29.078 [9]) at the GMSC; 

4) interworking between CS domain and the IM CN subsystem provided by an MGCF in accordance with 
3GPPTS 29.163 [10]; and 

5) capabiUty of the IP -CAN to support VoIP. 

If CAMEL is not used for terminating call procedures, then network configuration is required to ensure that terminating 
calls in the CS domain can be anchored (see subclause A.5.5). In this case the HSS(HLR) is configured to provide the 
IMRN back to any requesting GMSC and subsequent routeing to the IM CN subsystem takes place based on this 
IMRN. As there are no VCC-specific procedures involved, this is not described in clause 7. 

Editor's note: There are other configuration options for terminating procedures that are not covered by the above 
text. 

VCC can be provided using the following options to provide the data associated with the IMRN to the DTF: 

1) using a direct communication between the gsmSCF and the CAMEL service function and the DTF; or 

2) using ISUP call diversion mechanisms. If this mechanism is used it requires a MGCF that supports call 
diversion. This option requires appropriate peering arrangements to allow for transparency regarding the call 
diversion related parameters. 

4.3 URI and address assignments 

In order to support VCC to a subscriber the following URI and address assignments are assumed: 

a) in this version of the document, the VCC UE will be configured with both a VDI and a VDN in order to initiate a 
domain transfer. 3GPP TS 24.167 [6] specifies an optional mechanism whereby these parameters can be 
modified; 

b) the VCC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one to 
many public telecommunication numbers which should be the same in both the CS domain and IM CN 
subsystem. This public telecommunication number can be the MSISDN used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that VCC UE in the IM CN 
subsystem, or the VCC application can be configured to provide a functional relationship between separate 
numbers providing each of these identities; 

c) an IMRN is assigned that can reach a VCC application that can either support the VCC capabilities for that VCC 
UE, or otherwise locate the VCC application supporting the VCC capabilities for that VCC UE. The IMRNs can 
be dynamically allocated at the time calls are anchored in the IM CN subsystem or domain transfers from the IM 
CN subsystem to the CS domain are accepted. The IM CN subsystem is configured to treat the IMRN as a PSI; 

d) the MSISDN will be subject to routeing to the IM CN subsystem in order for anchoring to be performed by the 
VCC application. A CSRN is assigned to be able to route to the VMSC (via an MGCF) such that the CSRN is 
not subject to the same routeing back to the IM CN subsystem and the VCC application. The CSRN can be the 
MSRN for that call; and 

e) not all calls are suitable for domain transfer, and application of domain transfer to other calls might be against 
subscriber or operator preferences. 3GPP TS 22. 101 [1] Clause 21 provides the requirements for this. 
Subclause 5.5 of the present document specifies an additional prerequisite for allowing VCC to be applied to 
calls. 
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5 Functional entities 

5.1 Introduction 

This clause associates the functional entities described for the IM CN subsystem and for the CS domain, with the VCC 
roles described in the stage 2 architecture document (see 3GPP TS 23.206 [3]). 

5.2 User Equipment (UE) 

To be compliant with this document, a UE shall implement the role of a VCC UE (see subclause 6.2, subclause 7.2, 
subclause 8.2, subclause 9.2 and subclause 10.2). 

5.3 Media Resource Function Controller (MRFC) 

There are no roles specific to VCC associated with the MRFC. 

5.4 Application Server (AS) 

An AS shall implement the one or more of the roles of a VCC application: 

a) Domain Transfer Function (DTF) as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.1; 

b) Domain Selection Function (DSF) as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.2; 

c) CS Adaptation Function (CSAF) as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.3; 

d) CAMEL service function as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.4. 

5.5 Media Gateway Control Function (MGCF) 

In order to support VCC for any call, the MGCF has to provide signalling interworking and control of the media 
between the CS domain and the IM CN subsystem. The VCC application can only be configured to operate where 
appropriate interworking is provided, e.g. a voice call represented by SDP in the IM CN subsystem has an equivalent 
coding in the transmission media requirement and optionally the ISUP USI parameter in the CS domain. 

As the procedures for call termination in the CS domain may involve an MGCF provided by another network operator, 
the provision of appropriate interworking can extend to peering agreements between operators. 

6 Roles for registration in the IM CN subsubsystem 
6.1 Introduction 

The VCC application can be configured with any of various options for obtaining information from the IM CN 
subsystem specified in 3GPP TS 24.229 [8], 3GPP TS 29.328 [11] and 3GPP TS 29.329 [12], for example: 

a) receipt of REGISTER request which causes a third-party REGISTER request to be sent to the VCC application; 

b) receipt of REGISTER request which causes a third-party REGISTER request to be sent to the VCC application. 
The VCC application then subscribes to the reg event package for that user to obtain information; or 

c) receipt of REGISTER request which causes a third-party REGISTER request to be sent to the VCC application. 
The VCC application then uses the Sh interface to obtain information. 

This document places no requirement on the use of all or any of these mechanisms. 



£75/ 



3GPP TS 24.206 version 7.0.1 Release 7 1 1 ETSI TS 1 24 206 V7.0.1 (2007-1 0) 

6.2 VCC UE 

There are no VCC specific requirements for registration of the VCC UE to the the IM CN subsystem. 

NOTE 1: Depending on operator poHcy, registration to the IM CN subsystem can impact whether calls are 
delivered to the VCC UE using the IM CN subsystem or using the CS domain. 

NOTE 2: The VCC UE performs registration in the IM CN subsystem independent of the UE"s state in the CS 
domain. 

6.3 VCC application 

The VCC application can obtain information from any received third-party REGISTER request, or any received reg 
event package, or the Sh interface, that it needs to implement the domain selection policy of the network operator. 

If the third-party REGISTER request does not carry a P- Access-Network-Info header provided by the UE, and the VCC 
application requires this knowledge in for domain selection procedures, the mechanisms by which the VCC application 
determines the domain are outside the scope of this version of the specification, but could be dependent on configurable 
parameters in the DSF. 



7 Roles for call origination 

7.1 Introduction 

7.2 VCC UE 

The VCC UE shall support origination of calls suitable for VCC both via the CS domain (as specified in 
3GPP TS 24.008 [5]) and the IM CN subsystem (as specified in 3GPP TS 24.229 [8]). 

There are no VCC specific requirements for the origination of calls that may be subject to VCC. 

NOTE 1 : For INVITE requests initiated by the VCC UE in the IM CN subsystem, the following SIP response codes 
can indicate failure of the VCC application to process the request with its current characteristics: 

484 (Address Incomplete); 

- 488 (Not Acceptable Here) or 606 (Not Acceptable); 

503 (Service Unavailable) or 603 (Decline). 

NOTE 2: For SETUP messages initiated by the VCC UE in the CS domain, the following cause codes in a response 
message can indicate failure of the VCC capability to process the request with its current characteristics: 

- #21 "Call rejected"; 

#28 "Invalid number format (address incomplete); 
#127 "Interworking, unspecified". 

7.3 VMSC 

There is no VCC specific procedure at the VMSC. 

NOTE: the VMSC interacts with CAMEL to proceed with the call origination. 
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7.4 VCC application 

7.4.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to call origination: 

SIP INVITE requests routed to the VCC application over either the ISC interface or the Ma interface using the 
IMRN as a PSI, and therefore distinguished by the presence of the IMRN in the Request-URI header, and which 
are known by interaction with the gsmSCF functionality to relate to an originating request rather than a domain 
transfer request or a terminating request. In the procedures below such requests are known as "SIP INVITE 
requests due to originating IMRN". These requests are routed firstly to the CSAE and then to the DTE; and 

SIP INVITE requests routed to the VCC application over the ISC interface as a result of processing filter criteria 
at the S-CSCF according to the origination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.2), are 
distinguished by the contents of the Request-URI. If the Request-URI contains a VDI, then it is for a domain 
transfer request. However, absence of a VDI in the Request-URI indicates an origination request. In the 
procedures below such requests are known as "SIP INVITE requests due to originating filter criteria". These 
requests are routed firstly to the DTE. 

Subclause 8.4.1, subclause 9.3.1 and subclause 10.4.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

The VCC application (CAMEL service function) also processes requests from the gsmSCE via a protocol not defined in 
this version of the specification. 

NOTE: The functionality associated with these requests is described, based on the actions occurring at the 

interface between VMSC and gsmSCE, and is depending whether it relates to an originating request, 
containing an ordinary called party number, or relates to a domain transfer request, which contains a 
VDN as the called party number. 

7.4.2 Call origination in the IM CN subsystem 

When the DTE receives a SIP INVITE request due to originating filter criteria, the DTE shall: 

1) check anchoring is possible for this session; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, the present IP-CAN used to access the IM CN 
subsystem.. In general, the number of calls presented for anchoring on behalf of the same user, and the 
media characteristics relating to these calls, will not prevent anchoring, as these issues are dealt with at 
domain transfer. 

NOTE 2: Some checks can also form part of the initial filter criteria in the S-CSCE to determine if the SIP INVITE 
request is sent to the DTE in the first place, e.g. values of the P- Access-Network-Info header header could 
form part of the initial filter criteria. 

2) if the session is not subject to anchoring, either: 

a) forward the SIP INVITE request by acting as a SIP proxy as specified in subclause 5.7.4 of 

3GPP TS 24.229 [8], and therefore allow the call to continue without anchoring. The DTE shall not Record- 
Route on such requests, and the request is not retargetted by changing the Request-URI; or 

b) reject the SIP INVITE request. The following SIP response codes are recommended: 

- 484 (Address Incomplete), if the Request-URI supplied is not resolvable in the home network (such a 
Request-URI may have been resolvable in the local network which may be visited by the VCC UE at this 
time); 
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- 488 (Not Acceptable Here) or 606 (Not Acceptable), if some aspect of operator policy precluded 
anchoring; or 

503 (Service Unavailable) or 603 (Decline) for all other conditions; 

and no further VCC specific procedures are performed on this session; and 

3) if the session is subject to anchoring, operate as an application server providing 3' party call control, and 

specifically as a routeing B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all 
future requests and responses in the same dialog with the following additions: 

copy the Request-URI unchanged from the incoming SIP INVITE request to the outgoing SIP INVITE 
request; 

copy all other headers unchanged from the received SIP INVITE request to the outgoing SIP INVITE 
request; and 

copy the body unchanged from the received INVITE request to the outgoing SIP INVITE request. 

NOTE 3: Call anchoring is performed before all originating services are executed and thus the DTF is invoked as 
the first AS in the originating initial Filter Criteria. Example initial Filter Criteria can be found in 
annex B. 

7.4.3 Call origination in the CS domain - procedures towards the gsmSCF 

When the CAMEL service function receives an indication that the gsmSCF has received a CAMEL IDP relating to an 
originating call, containing a called party number that is not a VDN, the CAMEL service function shall: 

1) check anchoring is possible for this call; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available 
IMRNs. In general, the number of calls presented for anchoring on behalf of the same user will not 
prevent anchoring, as these issues are dealt with at domain transfer. 

2) if the session is not subject to anchoring, cause the gsmSCF to respond with a CAMEL CONTINUE and no 
further VCC specific procedures are performed on this call; and 

NOTE 2: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

3) if the session is subject to anchoring, allocate an IMRN. The IMRN is such that when the VCC application 
receives a SIP INVITE request it can derive by inspection that the request is due to an originating IMRN. How 
IMRNs are allocated may vary from one VCC application to another and is not specified in this version of the 
specification; 

4) if the session is subject to anchoring, cause the gsmSCF to respond with a CAMEL CONNECT message, as 
specified in 3GPP TS 29.078 [9], with the Destination Routing Address set to the IMRN, the Original Called 
Party ID, the Redirecting Party ID; and the Redirection Information. 

NOTE 3: The gsmSCF will include further parameters in the CAMEL CONNECT message as appropriate for the 
service key that was received in the CAMEL IDP. 

NOTE 4: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

7.4.4 Call origination in the CS domain - procedures towards IM CN 
subsystem 

When the CSAF receives SIP INVITE request due to originating IMRN, the CSAF and DTF in combination shall: 

1) operate as an application server providing 3"* party call control, and specifically as an initiating B2BUA, as 
specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all future requests and responses in the 
same dialog; 
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2) set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the original called 
party number of the call as initiated in the CS domain. The tel-URI may be available from information associated 
with the received IMRN or from the History-Info header; 

3) set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the original 
called party number of the call as initiated in the CS domain. The tel-URI may be available from information 
associated with the received IMRN or from the History-Info header; 

4) if the CS AF has received a History-Info header having an index parameter indicating only one diversion, not 
include the History-Info header; 

NOTE 1 : The History -Info header was received as a result of the option of using ISUP call diversion mechanisms 
to transfer VCC specific information and carries no information relating to a real diversion. 

5) append the orig parameter to the S-CSCF URI included in the Route header of the outgoing initial SIP INVITE 
request; and 

6) set the P-Asserted-Identity header of the outgoing SIP INVITE request and to a tel-URI which represents the 
calling party number of the call initiated in the CS domain. This is either available from information associated 
against the received IMRN or is the value as received in P-Asserted-Identity header of the incoming SIP INVITE 
request. 

NOTE 2: It can happen that the P-Asserted-Identity header is not included in the incoming SIP INVITE request. 

The CSAF and DTE in combination should in the outgoing SIP requests and SIP responses include the same values as 
received in the incoming SIP requests and SIP responses in all other headers with the exception given in this subclause 
and in subclause 5.7.5 of 3GPP TS 24.229 [8]. 

The DTF will handle the Privacy header in the outgoing SIP INVITE request in the following way. The DTF shall 
either: 

if a Privacy header is received in the incoming INVITE request, include the Privacy header as received in the 
incoming INVITE request; or 

if a value is associated to IMRN and indicates that the presentation of the calling party number is restricted in the 
CS domain, include a Privacy header with the value set to "id". 

Editor's note: Other actions are required to be specified, since the VCC AS works as an initiating B2BUA. 

Editor's note: The value of the P-Asserted-Identity header needs to be specified. 

On completion of the above procedure, the call is anchored in the DTF. 



8 Roles for call termination 

8.1 Introduction 

8.2 VCC UE 

The VCC UE shall support termination of calls suitable for VCC both via the CS domain (as specified in 
3GPP TS 24.008 [5]) and the IM CN subsystem (as specified in 3GPP TS 24.229 [8]). 

There are no VCC specific requirements for the termination of calls that may be subject to VCC. 

8.3 GMSC 

There is no VCC specific procedure at the GMSC. 
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NOTE: Call diversion from CS domain to IM CN subsystem is required to proceed call termination. Several 

techniques are available at the GMSC to implement the call diversion as described in 3GPP TS 23.206 [8] 
Annex A. Those techniques are implementation options. 

8.4 VCC application 

8.4.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to call termination: 

SIP INVITE requests routed to the VCC application over the ISC interface as a result of processing filter criteria 
at the S-CSCF according to the termination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.3), and 
therefore distinguished by the URI relating to this particular filter criteria appearing in the topmost entry in the 
Route header. In the procedures below such requests are known as "SIP INVITE requests due to terminating 
filter criteria". These requests are routed to the DTP and then to the DSF; and 

SIP INVITE requests routed to the VCC application over the Ma or ISC interface using the IMRN as a PSI, and 
therefore distinguished by the presence of the IMRN in the Request-URI header, which is different from the 
VDN. In the procedures below such requests are known as "SIP INVITE requests due to terminating IMRN". 
These requests are routed firstly to the CSAF and then to the DTE and then to the DSF. 

Subclause 7.4.1, subclause 9.3.1 and subclause 10.4.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

The CAMEL service function also processes requests from the gsmSCF via a protocol not defined in this version of the 
specification. 

NOTE: The functionality associated with these requests is described, based on the actions occurring at the 
interface between GMSC and gsmSCF. 

8.4.2 Call termination in the IM CN subsystem 

When the DTE receives a SIP INVITE request due to terminating filter criteria, the DTF shall: 

1) check anchoring is possible for this session; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available 
CSRNs. In general, the number of calls presented for anchoring on behalf of the same user will not 
prevent anchoring, as these issues are dealt with at handover. If anchoring fails, the call is presented to the 
user without anchoring. 

NOTE 2: Such a check can also form part of the initial filter criteria in the S-CSCF to determine if the SIP INVITE 
request is sent to the DTF in the first place. 

2) if the session is not subject to anchoring, the DTF shall forward the SIP INVITE request by acting as a SIP proxy 
as specified in subclause 5.7.4 of 3GPP TS 24.229 [8]. The DTF shall not Record-Route on such requests and no 
further VCC specific procedures are performed on this session; 

NOTE 3: The SIP AS that implements the DTF acting as a B2BUA - which performs the third-party call control - 
needs to be the last located application server to ensure that all application servers that need to remain in 
the path of a call after domain transfer will do so. Example initial Filter Criteria can be found in Annex B. 

3) if the session is subject to anchoring, operate as an application server providing 3"* party call control, and 
specifically as a routeing B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all 
future requests and responses in the same dialog; 
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4) if the session is subject to anchoring, from the DSF perform domain selection based on operator and user 
preferences, registration and call states and whether the session has media characteristics that are interworkable 
to the CS domain; 

5) if the IM CN subsystem is selected by the DSF, leave the Request-URI unchanged between the incoming SIP 
INVITE request and the outgoing SIP INVITE request; and 

6) if the CS domain is selected by the DSF, determine a CSRN using the CS AF and set the headers of the outgoing 
SIP INVITE request as follows: 

a) set the Request-URI of the outgoing SIP INVITE request to the CSRN; and 

b) set the To header field of the outgoing SIP INVITE request to the CSRN; 
On completion of the above procedure, the call is anchored in the DTF. 

8.4.3 Call termination in the CS domain - procedures towards the 
gsmSCF 

When the CAMEL service function receives an indication that the gsmSCF has received a CAMEL IDP relating to a 
terminating call, the CAMEL service function and DTF in combination shall: 

1) check anchoring is possible for this call; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available 
IMRNs. In general, the number of calls presented for anchoring on behalf of the same user will not 
prevent anchoring, as these issues are dealt with at handover. If anchoring fails, the call is presented to the 
user without anchoring. 

2) if the call is not subject to anchoring, cause the gsmSCF to respond with a CAMEL CONTINUE and no further 
VCC specific procedures are performed on this call; and 

NOTE 2: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

3) if the call is subject to anchoring, allocate an IMRN. How IMRNs are allocated may vary from one VCC 
application to another and is not specified in this version of the specification; 

NOTE 3: For call termination, different options on IMRN derivation are available as described in 
3GPP TS 23.206 [8] Annex A. 

4) if the call is subject to anchoring, cause the gsmSCF to respond with a CAMEL CONNECT message with the 
Destination Routing Address set to the IMRN. 

NOTE 4: The gsmSCF will include further parameters in the CAMEL CONNECT message as appropriate for the 
service key that was received in the CAMEL IDP. 

NOTE 5: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

8.4.4 Call termination in the CS domain - procedures towards IM CN 
subsystem 

When the CSAF receives SIP INVITE request due to terminating IMRN, the CSAF and DTF in combination shall: 

NOTE 1: All SIP INVITE requests directed to the VCC application using an IMRN are assumed to be suitable for 
VCC anchoring, because any checks have been performed in conjunction with the CAMEL procedures. 

1) operate as an application server providing 3"* party call control, and specifically as a routeing B2BUA, as 
specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all future requests and responses in the 
same dialog; 
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NOTE 2: The SIP AS that implements the DTP acting as a B2BUA - which performs the 3"^ party call control - 

needs to be the last located application server to ensure that all application servers that need to remain in 
the path of a call after domain transfer will do so. Example initial Filter Criteria can be found in annex B. 

2) set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the called party 
number of the original call as terminated in the CS domain. The tel-URI may be available from the received 
IMRN or from the "History-Info" header; and 

3) set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the called party 
number of the original call as terminated in the CS domain. The tel-URI may be available from the received 
IMRN or from the "History-Info" header. 

NOTE 3: If call diversion parameters from the "History-Info" header are used to retrieve the original called party 
number and the VCC call was subject to call diversion before it was routed to the GMSC, the DTP will 
restore the original call diversion information. If multiple call diversion has occurred, the redirecting 
number can be lost. 



9 Roles for domain transfer of a call from the CS 

domain to the IM CN subsystem 

9.1 Introduction 

9.2 VCC UE 

If the VCC UE determines that an ongoing call in the CS domain needs to be supported over the IM CN subsystem 
instead, e.g. based on radio conditions, then the VCC UE shall send a SIP INVITE request in accordance with 
3GPP TS 24.229 [8] subclause 5.1. The VCC UE shall populate the SIP INVITE request as follows: 

Editor's note: Do we need to specify that the ongoing call must be in the active state, i.e. that the CONNECT 
message has been sent? Working assumption should be that it has. 

Editor's note: It needs to be discussed how the received domain transfer request is correlated to any particular 
anchored call. 

1) the Request-URI set to the VDI; 

2) the To header field set to the VDI; 

3) the P-Preferred-Identity header set to the tel URI of the calling party of the MSISDN used in the CS domain call; 

and 

Editors Note: It is for FFS how the UE determines which Public User ID's to register and then subsequently use to 
ensure that requirement in 3) is met. 

4) the SDP payload set for a single media line with media type "audio", indicating all supported codecs for this 
media type, in accordance with subclause 6.1.1 and subclause 6.1.2 of 3GPP TS 24.229 [8]. 

If the VCC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then domain transfer has not occurred 
and the call will continue in the CS domain. 

NOTE 1 : If the VCC UE receives a SIP 480 (Temporarily Unavailable) response to the SIP INVITE request, then 
this can indicate that the VCC appUcation was unable to correlate the request to a single anchored call in 
the CS domain. 

NOTE 2: If the VCC UE receives a SIP 488 (Not Acceptable Here) response or a 606 (Not Acceptable) response to 
the SIP INVITE request, then this can indicate that the remote terminal was not able to support the media 
characteristics of the SIP INVITE request, e.g. because the remote user is in the CS domain and the 
MGCF/MGW in the path does not support the specified interworking. 
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When the VCC UE receives a CC DISCONNECT message from the network, the VCC UE shall comply with network 
initiated call release procedures as specified in 3GPP TS 24.008 [5]. 

9.3 VCC application 

9.3.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to domain transfer: 

SIP INVITE requests routed to the VCC application over the ISC interface as a result of processing filter criteria 
at the S-CSCF according to the origination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.2), and therefore 
distinguished by the URI relating to this particular filter criteria appearing in the topmost entry in the Route 
header, but which contains a VDI belonging to the subscribed user as the Request-URL In the procedures below 
such requests are known as "SIP INVITE requests due to VDI". These requests are routed to the DTF. 

Subclause 7.4.1, subclause 8.4.1 and subclause 10.4.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

9.3.2 Domain transfer in the IM CN subsystem 

When the DTF receives a SIP INVITE request due to VDI, the DTF shall send a SIP relNVITE request towards the 
remote user using the existing established dialog. The DTF shall populate the SIP relNVITE request as follows: 

set the Request-URI to the URI contained in the Contact header returned at the creation of the dialog with the 
remote user; and 

a new SDP offer, including the media characteristics as received in the SIP INVITE request due to VDI, by 
following the rules of the RFC 3264 [16]. 

Editor's note: Need to specify actions when multiple calls are currently anchored. This may include special 
procedures when all but one of the calls are held calls. 

Upon receiving the SIP ACK request from the IM CN Subsystem, the DTF shall initiate release of the old access leg by 
sending a SIP BYE request toward the MGCF. 

9.4 MGCF 

There are no VCC specific procedures at the MGCF beyond those specified by 3GPP TS 29.163 [10]. 

NOTE: When the SIP BYE request is received, the MGCF translates the SIP BYE request to an ISUP REL 

message as specified in 3GPP TS 29.163 [10] and forwards this to the VMSC. The VMSC responds with 
ISUP RLC message and performs network initiated call release as specified in 3GPP TS 24.008 [5]. 
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1 Roles for domain transfer of a call from the IM CN 
subsystem to the CS domain 

10.1 Introduction 

10.2 VCCUE 

If the VCC UE determines that an ongoing call in the IM CN subsystem should be transferred to the CS domain, e.g. 
based on radio conditions, then the VCC UE shall send a CC SETUP message in accordance with 3GPP TS 24.008 [5]. 
The VCC UE shall only send this request if the ongoing call in the IM CN subsystem has had the dialog accepted, i.e. a 
SIP 200 (OK) response to the SIP INVITE request has already been sent. 

NOTE 1 : If the VCC UE has multiple calls in the IM CN subsystem at this time, then these calls could all be 
anchored. It is the responsibility of the VCC UE to ensure that the domain transfer request can be 
resolved by the DTF to a single call. 

NOTE 2: The current media characteristics of the call in the IM CN subsystem does not preclude domain transfer, 
as the media characteristics are renegotiated as part of the domain transfer. 

The VCC UE shall populate the CC SETUP message as follows: 

Editor's note: Do we need to specify that the ongoing call must be in the active state, i.e. that the 2xx response to the 
INVITE request has been sent? Working assumption should be that it has. 

1) the called party BCD number information element set to the VDN; and 

2) [need to ensure suitable bearer characteristics] 

NOTE 3: If the VCC UE receives a release message containing a #20 "Subscriber absent" cause value to the CC 
SETUP message, then this can indicate that the VCC application was unable to correlate the request to a 
single anchored call in the IM CN subsystem. 

NOTE 4: If the VCC UE receives a release message containing a #127 "Interworking, unspecified" cause value to 
the CC SETUP message, then this can indicate that the remote terminal was not able to support the media 
characteristics of the CC SETUP message. 

10.3 VMSC 

There is no VCC specific procedure at the VMSC. 

10.4 VCC application 

1 0.4.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to domain transfer: 

SIP INVITE requests routed to the VCC application over either the ISC interface or the Ma interface using the 
IMRN as a PSI, and therefore distinguished by the presence of the IMRN in the Request-URI header, and which 
are known by interaction with the gsmSCF functionality to relate to a domain transfer request rather than an 
originating request or terminating request. In the procedures below such requests are known as "SIP INVITE 
requests due to domain transfer IMRN". These requests are routed to the DTF. 

Subclause 7.4.1, subclause 8.4.1 and subclause 9.3.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 
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Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

The VCC application (CAMEL service function) also processes requests from the gsmSCF via a protocol not defined in 
this version of the specification. 

NOTE: The functionality associated with these requests is described, based on the actions occurring at the 

interface between VMSC and gsmSCF, and is depending whether it relates to an originating request, 
containing an ordinary called party number, or relates to a domain transfer request, which contains a 
VDN as the called party number. 

1 0.4.2 Domain transfer procedures towards the gsmSCF 

When the CAMEL service function receives an indication that the gsmSCF has received a CAMEL IDP relating to an 
originating call, containing a called party number that is a VDN, the CAMEL service function shall: 

1) check whether domain transfer is possible; 

NOTE 1 : The conditions that prevent handover are a matter for implementation, but in general for this check are a 
matter of lack of resources, e.g. available IMRNs. For other checks the request will be continued so 
further checks can be performed at the VCC application within the IM CN subsystem. 

Editor's note: Need to specify actions when multiple calls are currently anchored. This may include special 
procedures when all but one of the calls are held calls. 

2) if the call is not subject to domain transfer, cause the gsmSCF to respond with a CAMEL RELEASE CALL and 
no further VCC specific procedures are performed on this call. The following cause codes are recommended: 

480 (Temporarily Unavailable) if there are insufficient resources, e.g. available IMRNs, to continue the 
handover; 

NOTE 2: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

3) if the call is subject to domain transfer, allocate an IMRN. The IMRN is such that when the VCC application 
receives a SIP INVITE request it can derive by inspection that the request is due to a domain transfer IMRN. 
How IMRNs are allocated may vary from one VCC application to another and is not specified in this version of 
the specification; 

4) if the call is subject to domain transfer, cause the gsmSCF to respond with a CAMEL CONNECT message with 
the Destination Routing Address set to the IMRN. 

NOTE 3: The IMRN assigned for a domain transfer request can be different from the one assigned for CS 

origination (different target PSI i.e. different subfunction of the VCC application) and can be used as an 
indication of a domain transfer request. 

NOTE 4: The gsmSCF will include further parameters in the CAMEL CONNECT message as appropriate for the 
service key that was received in the CAMEL IDP. 

NOTE 5: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

10.4.3 Domain transfer in tine IM CN subsystem 

When the DTE receives SIP INVITE request due to domain transfer IMRN, the DTF shall associate the SIP INVITE 
request with an ongoing SIP dialog and send a SIP relNVITE request towards the remote user using the existing 
established dialog. The DTF shall populate the SIP relNVITE request as follows: 

set the Request-URI to to the URJ contained in the Contact header returned at the creation of the dialog with the 
remote user; and 

a new SDP offer, including the media characteristics as received in the SIP INVITE request due to domain 
transfer IMRN, by following the rules of the RFC 3264 [16]. 
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Editor's note: Need to specify actions when multiple calls are currently anchored. This may include special 
procedures when all but one of the calls are held calls. 

On completion of the above procedure, the call is anchored in the DTP. 

Upon receiving the SIP ACK request from the IM CN Subsystem, the DTP shall initiate release of the old access leg by 
sending a SIP BYE request toward the S-CSCP for sending to the served VCC UE. 
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Annex A (informative): 

Example signalling flows of voice call continuity between the 
Circuit-Switched (CS) domain and the IP Multimedia (IM) 
Core Network (CN) subsystem 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for voice call continuity between the Circuit-Switched (CS) domain and 
the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.206 [3]. 



A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [7]. The following 
additional considerations apply: 

a) 3GPP TS 24.228 [7] shows separate signalling flows with no configuration hiding between networks, and with 
configuration hiding between networks. There is no voice call continuity specific functionality associated with 
this hiding, and therefore such separate signalling flows are not show in the present document; 

b) 3GPP TS 24.228 [7] does not show the functionality between the S-CSCF and the AS. As voice call continuity 
depends on the functionality provided by various AS, the signalling flows between S-CSCF and AS are shown in 
the present document; 

c) 3GPP TS 24.228 [7] breaks down the functionality of the various CSCFs. Such intervening activity in the CSCFs 
is in general not relevant to showing the functionality within voice call continuity, and therefore the CSCFs are 
collapsed into a single entity labelled "Intermediate IM CN subsystem entities"; 

d) where entities are combined as in c) above, and the signalling flow is directed to such a combined entity, the 
contents of the signalling flow represent the contents of the sending entity; 

e) where entities are combined as in c) above and the signalling flow originates at such a combined entity, the 
contents of the signalling flow represent the contents of the receiving entity; and 

f) within the CS domain, both ISUP and BICC can be used. The signalling flows represent only the ISUP 
signalling flows, and the BICC signalling flows (which can be assumed to be similar with no additional VCC 
specific content) are not shown. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [7] subclauses 4. 1 and 4.2 applies with the additions 
specified below: 

- tel:H-l-241-555-3333 represents the IMRN associated with a call made by UE#1. 

sip:as. homel.net represents the address within the IM CN subsystem of the AS providing the VCC application. 

- tel:H-l-241-555-4444 represents the CSRN associated with a call made by UE#1. 

- tel:H-l-212-555-5555 represents the VFN associated with UE#1. 
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sip:domain.xfer@cccfl. homel.net represents the VFI associated with UE#1. 



Editor's note: Need to include here any specify addressing concepts associated with the flows for voice call 
continutity. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [7]. 

However, 3GPP TS 24.228 [7] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [7], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [7] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A. 2-1 is used. 



INVITE 



SETUP 



-► SIP message 

-► CS message 

►" Media over a PS connection 

► Media over a CS connection 



Figure A.2-1 : Signalling flow notation 



A.3 Signalling flows for registration and exchange of 
mobility status information 

There are no VCC specific signalling flows. 

A.4 Signalling flows for call origination 
A.4.1 Introduction 

The signalling flows for call origination demonstrate how a VCC UE, on originating a call, is anchored for the purposes 
of a future domain transfer. The following signalling flows are included: 

subclause A.4. 2 shows the successful anchoring for a call originated using the IM CN subsystem; 

subclause A.4. 3 shows the successful anchoring for a call originated using the CS domain, by routeing the call to 
the IM CN subsystem using CAMEL; 

subclause A.4.4 shows the successful anchoring for a call originated using the CS domain, by routeing the call to 
the IM CN subsystem using CAMEL and routeing the call from the VCC application to the terminating 
subscriber using information received in the SIP History-Info header; and 

subclause A.4. 5 shows a call originated from the CS domain for which the anchoring is denied; the call is 
continued in the CS domain. 
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A.4.2 Signalling flows for origination from the IIVI CN subsystem 

Editors note: When stage 2 specification has become clearer regarding how supplementary services shall be 

provided it may be needed to add an additional AS to test that the services are executed in the same 
manner indepent from where the session is initiated. 
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VCCUE 
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domain 



Intermediate IM 
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(AS side) 



-2. SiP iNViTE- 



-3. SIP 100 (Trying)- 



4. Initiai fiiter 
criteria 



-5. SIP INVITE- 



-6. SIP100{Trying)- 



-8. SIP INVITE- 



7. Anchoring 
desicion 



-9. SIP 100 (Trying) - 



10. Initial filter 
criteria 



-11. SIP INVITE- 



-13d. SIP 183/PRACK/200/180- 



-17. SIP 200 (OK)- 
— 18. SIPACK — 



-12. SIP100(Trying)- 



-13a. SIP 183/PRACK/200/180- 



-13b. SIP 183/PRACK/200/180- 
-13c. SIP 183/PRACK/200/180- 



-14. SIP 200 (OK)- 



-15. SIP 200 (OK)- 



-16. SIP 200 (OK)- 



-19. SIPACK- 
-20. SIPACK- 



-21.SIPACK- 



Figure A.4.2-1 : Signalling flow for origination from the IM CN subsystem 
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1 . Determination of call establishment domain 

As a result of some stimulus to establish a call with full duplex, voice-only call, the VCC UE based on a 
combination of user policy, and access technology availability, decides to establish the call using the IM CN 
subsystem. 

The VCC UE initiates the IM CN subsystem call towards the destination UE by sending a SIP INVITE request 
to the intermediate IM CN subsystem entities. 

2. SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) - see example in table A.4.2-2 

Table A.4.2-2: SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : sip :pcscf 1 .homel .net : 7531; Ir ; comp=sigcomp> , <sip lorigOscscf 1 .homel .net; lr> 

P-Preferred-Identity: <tel: +l-212-555-llll> 

P-Access-Network-Info: IEEE-WLAN-802 . lib 

Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 

Contact: < sip: [5555 : : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: the tel-URI of the destination 

3. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities respond to the VCC UE with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

4. Evaluation of initial filter criteria 

In this example, and by evaluation of the initial filter criteria, as this is an originating SIP INVITE request for a 
registered VCC user the S-CSCF routes the SIP INVITE request to the VCC application. 

Editors note: The criteria that makes the IM CN subsystem to address the request is for further study. 

5. SIP INVITE request (intermediate IM CN subsystem entities to VCC application) - see example in 
table A.4.2-5 

The intermediate IM CN subsystem entitities send the SIP INVITE request to the VCC application. 

As part of this operation, the S-CSCF adds the address of the VCC application and the original dialog identifier. 
The S-CSCF will include the original dialog identifier as a part of the second topmost Route header. The 
Request-URI includes the tel-URI of the destination. 



ETSI 



3GPP TS 24.206 version 7.0.1 Release 7 27 ETSI TS 124 206 V7.0.1 (2007-10) 

Table A.4.2-5: SIP INVITE request (intermediate IM CN subsystem entities to VCC application) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 67 

Route : <sip : as .homel .net ; lr>, <sip : Cb03a0s09a2sdfglkj490333@scscf 1 .homel .net ; lr> 
Record-Route : <sip : scscf 1 . homel . net> 
P-Asserted-Identity: <tel: +l-212-555-llll> 
P-Access-Network-Inf o : 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig- 
ioi=type3ashomel . net> 

P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a5 5:b44:c33:d22] 
ecf= [5555 : : If f : 2ee : 3dd : 4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
Cseq: 127 
Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



6. SIP 100 (Trying) response (VCC application to intermediate IM CN subsystem entities) 

The VCC application responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

7. Anchoring decision 

The VCC application performs the anchoring. 

8. SIP INVITE request (VCC application to intermediate IM CN subsystem entities) - see example in 
table A.4.2-8 

Since the service execution continues as an originating case the VCC application, after executing the anchoring, 
sends the SIP INVITE request with a Route header that includes the original call identifier in the Route header to 
the intermediate IM CN subsystem entities. 

The VCC application works in this case as a routeing B2BUA. In particular, the To and From header fields 
remain unchanged. It will not include any entry in the Record-Route header. The AS does not change any 
codecs. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.4.2-8: SIP INVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2 .0/UDP. as. homel.net; branch=z9hG4bK332b23 . 3 ; 

Max-Forwards: 66 

Route: <sip:cb03aOs09a2sdfglkj490333®scscf 1 .homel .net;lr > 

P-Asserted- Identity : 

P-Access-Network-Info : 

Privacy: none 

P- Charging- Vector : icid-value = "AyretyU0dm+602IrT5tAFrbHLso=023551024'' 

P-Charging-Function-Addresses : 

From: 

To: 

Call-ID: 

Cseq: 127 

Supported: 

Contact :<sip: [7777: :eee :ddd: ccc : aaa] > 

Allow: 

Content-Type : 

Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



Request-URI: includes the tel-URI of the destination. 
Contact: address of the VCC apphcation. 

9. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities respond to the VCC application with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

10. Evaluation of initial filter criteria 

In this example, the S-CSCF continues the triggering from the next trigger point (originating request registered 
user) in the initial filter criteria. Since no more triggering is required in the initial filter criteria, the IM CN 
subsystem will do a ENUM look up and get the SIP-URI for the destination user. 

1 1 . SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see example 
in table A.4.2-11 

The intermediate IM CN subsystem sends a SIP INVITE request towards the terminating side. 
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Table A.4.2-11 : SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP as.homel.net; 

branch=z9jG4bK332b23 .2 
Max- Forwards : 6 5 

Record-Route : sip . scscf 1 . homel . net 
P-Asserted- Identity : 
Privacy: none 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" , orig-ioi=homel .net 
From 
To: 

Call-ID 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



12. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing responds to the to the intermediate IM CN subsystem entities with a SIP 100 
(Trying) response. 

There is no VCC specific content to this response. 

13a-d. SIP 183 (Session Progress) response / SIP PRACK request / SIP 200 (OK) response / SIP 180 (Ringing) 
response 

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the 
IP-C/VN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC 
imposes no restriction on this operation. 

14. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing forwards a SIP 200 (OK) response to the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this response. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the VCC application. 
There is no VCC specific content to this response. 

16. SIP 200 (OK) response (VCC application to intermediate IM CN subsystem entities) 

The VCC application forwards the SIP 200 (OK) response to the intermediate IM CN subsystem entities, using 
the content of the Via header in the received SIP INVITE request (step 5). 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 
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There is no VCC specific content to this response. 

17. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the VCC UE. 
There is no VCC specific content to this response. 

18. SIP ACK request (VCC UE to intermediate IM CN subsystem entities) 

The VCC UE completes the dialog creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this request. 

19. SIP ACK request-(intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the VCC application. 
There is no VCC specific content to this request. 

20. SIP ACK request (VCC application to intermediate IM CN subsystem entities) 

The VCC application forwards the SIP ACK request to the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

21. SIP ACK request (intermediate IM CN subsystem entities to terminating side processing) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing. 
There is no VCC specific content to this request. 

A.4.3 Signalling flows for origination from CS domain 

Figure A.4.3- 1 shows the origination of a call in the CS domain that is capable of being subject to VCC. 

Editor's note: In the following figure, the naming and breakdown of the core functionality of VCC is still under 
discussion. The separation of the functionality into CS side and AS side is not meant to pre-empt that 
discussion within SA2, but merely provide a convenient manner of showing the operation of the same 
application when it forms part of the CS side call flow, versus when it forms part of the IM CN subsystem 
call flow. The naming of the columns should be modified in the future based on the ongoing stage 2 
architecture discussion. Additionally thoughout this text, the AS is referred to as the VCC application, 
and this can be made more specific when the SA2 decisions are made. 
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Figure A.4.3-1 : CS call origination from the VCC user 

The details of the signalling flows are as follows: 
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1 Determination of call establishment domain 

As a result of some stimulus to establish a full-duplex, voice-only call, the VCC UE based on a combination of 
user policy, and access technology availability, decides to establish the call using the CS domain. 

2. SETUP message (VCC UE to VMSC) 

After establishment of the MM connection, the VCC UE initiates the CS call towards the destination UE by 
sending out the SETUP message. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits = 12125552222)] 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR 
AMR, GSM EFR, GSM PR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The Called Party Number information element identifies the intended recipient of the call, and the Bearer 
Capability information element and the Supported Codec List information element identify an intended call that 
can be subject to VCC. 

Editor's note: There is ongoing discussion in SA2 as to whether any specific VCC information needs to be provided 
by the UE. 

The VMSC knows the calling party number corresponding to the UE. 

3. Origination triggers 

4. CAMEL IDP (VMSC to gsmSCF) 

The VMSC triggers a CAMEL activity which results in sending a CAMEL IDP message to the gsmSCF. The 
CAMEL IDP message contains at least: 

the calling party number; 

the called party number; and 

that the call is voice only. 

5. Anchor decision 

The gsmSCF invokes the service logic to determine whether the call needs to be rerouted to IMS for VCC. The 
VCC Application allocates an IMRN and returns it to the gsmSCF. 

6. CAMEL CONNECT (VCC appUcation to VMSC) 

The gsmSCF responds to the CAMEL IDP message with a CAMEL CONNECT message containing: 
the Destination Routeing Address set to the IMRN. 

7. ISUP lAM (VMSC to MGCP) 

The VMSC initiates the CS call towards the MGCF by sending out the lAM message. 

Specifically for this signalling flow, the lAM includes: 

Called Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12415553333)] 

Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12125551 1 11)] 

- USI parameter = 3.1 kHz audio 
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The Called Party Number parameter represents the IMRN allocated for this call. 

8. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.4.3-8 

The MGCF initiates a SIP INVITE request, containing an initial SDP to the intermediate IM CN subsystem 
entities. 

Table A.4.3-8: SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 

Max- Forwards : 7 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode- change -period=2 

a = r tpmap :96 telephone- event 

a=maxpt ime : 2 



Request-URI: Contains the IMRN, as obtained from CS Networks signalling. 

P-Asserted-Identity: The MGCF inserts the tel-URL containing the subscriber number, as received from the CS 
network. 

SDP The SDP contains a preconfigured set of codecs supported by the MGW based on what is 

received in the ISUP. The codecs selected are speech codecs, for which VCC can be applied. 
See table 10a of 3GPP TS 29.163 [10] 

9. SIP INVITE request (intermediate IM CN subsystem entities to VCC application) - see example in 
table A.4.3-9 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the VCC 
application. In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, 
there is no IBCF before the I-CSCF and no intermediate entities Record-Route the request. 
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Table A.4.3-9: SIP INVITE request (intermediate IM CN subsystem entities to VCC application) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 0, SIP/2. 0/UDP 

icscf l_s .homel .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 69 
Route: <sip : as .homel .net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=type 

3homel.net; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
ra= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. SIP 100 (Trying) response (VCC application to intermediate IM CN subsystem entities) 

There is no VCC specific content to this response. 

The VCC application responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

1 1 . Session anchoring 

The VCC application acts as a routeing B2BUA. The VCC application retrieves the original called party number 
and calling party number associated with the IMRN and places the called party number in the Request-URl and 
the To header of the outgoing request. 

The VCC application decides that this call will be anchored, based on the type of call and operator preferences. 

Editor's note: The following text needs further study. 

The VCC application found by the IMRN need not be the most appropriate AS to support the handover of the 
call on behalf of the UE in the IM CN subsystem. In these cases it is possible that the VCC application redirects 
the call to another applications server which provides the future transfer functions on behalf of the VCC user. 
How this occurs is outside the scope of this document. 

12. SIP INVITE request (VCC application to intermediate IM CN subsystem entities) - see example in 
table A.4.3-12 

The VCC application forwards the SIP INVITE request to the S-CSCF serving the originating user within the IM 
CN subsystem. In this case it is assumed that the user is registered within the IM CN subsystem. 

The VCC application sets the value of the Contact header with the address of the VCC application that will 
provide the transfer functionality needed to support VCC. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.4.3-12: SIP INVITE request (VCC application to intermediate IIVI CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2 .0/UDP;branch=z9hG4bK312a32 .1 

Max-Forwards: 68 

Route : <sip:s-cscf .homel .net; lr;orig> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltlOb3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip : as .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



Contact header: The Contact header represents the contact of the VCC application. 

13. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities respond to the VCC application with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

14. SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see 
example in table A.4.3-14 

The intermediate IM CN subsystem entities route the SIP INVITE request to the terminating side processing. In 
this example, there is no intermediate IBCF and none of the intermediate entities Record-Route. 
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Table A.4.3-14: SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2 . 0/UDP;branch=z9hG4bK312a32 .1 

Max- Forwards : 68 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



15. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) 
response. 

There is no VCC specific content to this response. 

16. SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC 

UE) 

The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and 
access signalling messages are transferred to indicate this is occurring. At or before this time, completion of 
negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no VCC specific actions associated 
with this step. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

17. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

A SIP 200 (OK) response is received from the terminating side processing by the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this response. 

18. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the VCC application. 
There is no VCC specific content to this response. 

19. SIP 200 (OK) response (VCC application intermediate to IM CN subsystem entities) 

The VCC application forwards the SIP (200) OK response back to the intermediate IM CN subsystem entities. 
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The VCC UE modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

Editor's note: There is currently no indication that the internal state of the VCC application should alter when the 
call is answered. Does this mean that domain transfer can occur on calls that have not been answered in 
an identical fashion to those that have been answered, or does it mean that some other means of 
controlling this is effected. 

-20. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF. 
There is no VCC specific content to this response. 

21. ISUP ANM (MGCF to VMSC) 

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the 
VMSC. 

There is no VCC specific content to this response. 

22. CONNECT message (VMSC to VCC UE) 

The VMSC sends a CONNECT message to the VCC UE. 
There is no VCC specific content to this response. 

23. CONNECT ACKNOWLEDGE message (VCC UE to VMSC) 

The VCC UE generates the CONNECT ACKNOWLEDGE message on receipt of the CONNECT message. 
There is no VCC specific content to this response. 

24. SIP ACK request (MGCF to intermediate IM CN subsystem entities) 

The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the 
intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

25. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

26. SIP ACK request (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the VCC application. 
There is no VCC specific content to this response. 

27. SIP ACK request (VCC application to intermediate IM CN subsystem entities) 

The VCC application forwards the SIP ACK request back to the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

28. SIP ACK request (intermediate IM CN subsystem entities to terminating side processing) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing. 
There is no VCC specific content to this response. 
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Editor's note: There are currently no stage 2 flows indicating any action on the call being cleared. Is VCC action 

needed at call termination, or is VCC state cleared up in some other manner. If VCC state is cleared up on 
call clearing, is this performed on the CS side transaction, on the IMS side transaction, or both. 

Editor's note: There are currently no stage 2 flows indicating any action on the call failing (i.e. 3xx, 4xx, 5xx or 6xx 
response. Is VCC action needed at call failure, or is VCC state cleared up in some other manner. If VCC 
state is cleared up on call clearing, is this performed on the CS side transaction, on the IMS side 
transaction, or both. 

Editor's note: There are currently no stage 2 flows indicating any action on the UPDATE or re INVITE requests that 
could negotiate a set of media that cannot be subject to VCC. Is VCC action needed at such relNVITES, 
or is VCC state cleared up in some other manner. If VCC state is cleared up on call clearing, is this 
performed on the CS side transaction, on the IMS side transaction, or both. 

Editor's note: If a 3xx response to INVITE is received, then 24.229 allows entities within the IM CN subsystem to 
redirect the call. This could include entities between the MGCF and the VCC application. Presumably 
such redirection should not be allowed, as this means that the anchor has not completed by being passed 
through from the IMS side. This presumably means that the VCC application must capture 3xx responses 
and do something sensible with them, or else they must get back to the MGCF and cause the call to fail 
back to the user on the CS side. Redirection is not allowed in ISUP except with some national variants, 
but it is allowed within SIP and is caused by the 3xx response. 

Editor's note: The IMRN is available for reuse when the call has been established, event though it is used in the 
To/From header. 

A.4.4 Signalling flows for origination from CS domain, using ISUP 
call diversion mechanisms 

Figure A.4.4- 1 shows the origination of a call in the CS domain that is capable of being subject to VCC. In the example 
below it is assumed that the gsmSCF based on the service key returns the parameters Original Called Party ID, 
Redirecting Party and Redirection information. Further it is assumed that the corresponding ISUP parameters are later 
on mapped in the MGCF to appropriate SIP header fields. 

Editor's note: In the following figure, the naming and breakdown of the core functionality of VCC is still under 
discussion. The separation of the functionality into CS side and AS side is not meant to pre-empt that 
discussion within SA2, but merely provide a convenient manner of showing the operation of the same 
application when it forms part of the CS side call flow, versus when it forms part of the IM CN subsystem 
call flow. The naming of the columns should be modified in the future based on the ongoing stage 2 
architecture discussion. Additionally thoughout this text, the AS is referred to as the VCC application, 
and this can be made more specific when the SA2 decisions are made. 
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Figure A.4.4-1 : CS call origination from the VCC user 

The details of the signalling flows are as follows: 
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1 Determination of call establishment domain 

As a result of some stimulus to establish a full-deplex, voice-only call, the VCC UE based on a combination of 
user policy, and access technology availability, decides to establish the call using the CS domain. 

2. SETUP message (VCC UE to VMSC) 

After establishment of the MM connection, the VCC UE#1 initiates the CS call towards UE#2 by sending out the 
SETUP message. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits = 12125552222)] 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = PR 
AMR, GSM EFR, GSM FR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The Called Party Number information element identifies the intended recipient of the call, and the Bearer 
Capability information element and the Supported Codec List information element identify an intended call that 
can be subject to VCC. 

Editor's note: There is ongoing discussion in SA2 as to whether any specific VCC information needs to be provided 
by the UE. 

The VMSC knows the calling party number corresponding to the UE. 

3. Origination triggers 

4. CAMEL IDP (VMSC to VCC application) 

On receipt of the SETUP message, the VMSC triggers a CAMEL activity which results in sending a CAMEL 
IDP message to the gsmSCF. The CAMEL IDP message contains at least: 

the calling party number; 

service key assigned to the subscriber; 

the called party number; and 

that the call is voice only. 

5. Anchor decision 

The VCC application decides that this call will be anchored, based on the type of call and operator preferences. 

6. CAMEL CONNECT (VCC appUcation to VMSC) 

The VCC application in this example causes the gsmSCF to respond to the CAMEL IDP message with a 
CAMEL CONNECT message containing: 

the Destination Routing Address set to the IMRN; 

- the Original Called Party ID; 
Redirecting Party ID; and 
Redirection Information. 

7. ISUP lAM (VMSC to MGCP) 

The VMSC initiates the CS call towards the MGCF by sending out the lAM message. 
Specifically for this signalling flow, the lAM includes: 



ETSI 



3GPP TS 24.206 version 7.0.1 Release 7 41 ETSI TS 124 206 V7.0.1 (2007-10) 

Called Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12415553333)] 

Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12125551 1 1 1)] 

USI parameter = 3.1 kHz audio 

Original Called Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type 
of number = international number ), (Number digits = 12125552222)] 

Redirecting Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12125552222)] 

Redirection information = [(Redirecting indicator = call diverted, all redirection info presentation 
restriceted), (Original redirection reason = unknown), (Redirection counter =1), Redirecting reason = 
unknown)] 

The Called Party Number parameter represents the IMRN allocated for this call. 

8. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.4.4-8 

The MGCF initiates a SIP INVITE request, containing an initial SDP. The MGCF in this example needs to 
support call diversion. 

Table A.4.4-8: SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 .homel .net ;branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route : <sip : icscf l_s . homel . net ; lr> 

P- Asserted- Identity: <tel :+l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel : +1-212 -555- 1111> ; tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip :mgcfl .homel .net> 

History-Info: <tel : +l-212-555-2222>; index=l, < tel : +l-212-555-2222>; \cause=404 ; index=l.l 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



Request-URI: Contains the IMRN, as obtained from CS domain signalling. 

P-Asserted-Identity: The MGCF inserts the tel-URL containing the calling party number as received from the CS 
network. 

SDP The SDP contains a preconfigured set of codecs supported by the MGW based on what is 

received in the ISUP. The codecs selected are speech codecs, for which VCC can be applied. 
See table 10a of 3GPP TS 29.163 [10]. 



£75/ 



3GPP TS 24.206 version 7.0.1 Release 7 42 ETSI TS 124 206 V7.0.1 (2007-10) 

Editor's note: How transparent the VCC application is to the SDP, and how much it participates in the offer/answer 
exchanges, requires further study. 

History-Info: The MGCF inserts the original called party number and an entry for the redirecting number 

as received from the CS network. 

9. SIP INVITE request (intermediate IM CN subsystem entities to VCC application) - see example in 
table A.4.4-9 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the VCC 
application. In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, 
there is no IBCF before the I-CSCF and no intermediate entities Record-Route the request. 

Table A.4.4-9: SIP INVITE request (intermediate IM CN subsystem entities to VCC application) 



INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 .0, SIP/2. 0/UDP 

icscf l_s .homel .net ;branch=z9hG4bK312a32 . 1 
Max-Forwards: 69 
Route: <sip : as .homel .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=type 
3homel.net; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
History-Info : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

ra= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. SIP 100 (Trying) response (VCC application intermediate to IM CN subsystem entities) 

There is no VCC specific content to this response. 

11. VCC application 

The VCC application acts as a routeing B2BUA. The VCC application places the original call party number in 
the Request-URI and the To header of the outgoing request and removes the History-Info header. 

12. SIP INVITE request (VCC application to intermediate IM CN subsystem entities) - see example in 
table A.4.4-12 

The VCC application forwards the SIP INVITE request to the S-CSCF serving the originating user within the IM 
CN subsystem. In this case it is assumed that the user is registered within the IM CN subsystem. 

The VCC application sets the value of the Contact header with the address of the VCC application that will 
provide the transfer functionality needed to support VCC. 
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Table A.4.4-12: SIP INVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2 .0/UDP;branch=z9hG4bK312a32 .1 

Max-Forwards: 68 

Route : <sip : s-cscf . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltlOb3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip : as .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



Editor's note: Need to add "orig" parameter to above table. 

Contact header: The Contact header represents the contact of the VCC application. 

13. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC application) 

There is no VCC specific content to this response. 

14. SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see 
example in table A.4.4-14 

The intermediate IM CN subsystem entities route the SIP INVITE request to the terminating side. In this 
example, there is no intermediate IBCF and none of the intermediate entities Record-Route. 
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Table A.4.4-14: SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2 . 0/UDP;branch=z9hG4bK312a32 .1 

Max-Forwards: 68 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



15. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

There is no VCC specific content to this response. 

16. SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC 

UE) 

Editor's note: The flows around here need to be revised to reflect the VCC specific needs of the SDP negotiation. 
This requires further study. 

The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and 
access signalling messages are transferred to indicate this is occurring. At or before this time, completion of 
negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no VCC specific actions associated 
with this step. 

The VCC UE modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

17. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

There is no VCC specific content to this response. 

18. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 
There is no VCC specific content to this response. 

19. SIP 200 (OK) response (VCC application intermediate to IM CN subsystem entities) 

There is no VCC specific content to this response. 

Editor's note: There is currently no indication that the internal state of the VCC application should alter when the 
call is answered. Does this mean that domain transfer can occur on calls that have not been answered in 
an identical fashion to those that have been answered, or does it mean that some other means of 
controlUng this is effected. 
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The VCC UE modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

There is no VCC specific content to this response. 

21. ISUP ANM (MGCF to VMSC) 

There is no VCC specific content to this response. 

22. CONNECT (VMSC to VCC UE) 

There is no VCC specific content to this response. 

23. CONNECT ACKNOWLEDGE (VCC UE to VMSC) 
There is no VCC specific content to this response. 

24. SIP ACK request (MGCF to intermediate IM CN subsystem entities) 
There is no VCC specific content to this response. 

25. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

26. SIP ACK request (intermediate IM CN subsystem entities to VCC application) 
There is no VCC specific content to this response. 

27. SIP ACK request (VCC application to intermediate IM CN subsystem entities) 
There is no VCC specific content to this response. 

28. SIP ACK request (intermediate IM CN subsystem entities to terminating side processing) 

There is no VCC specific content to this response. 

Editor's note: There are currently no stage 2 flows indicating any action on the call being cleared. Is VCC action 

needed at call termination, or is VCC state cleared up in some other manner. If VCC state is cleared up on 
call clearing, is this performed on the CS side transaction, on the IMS side transaction, or both. 

Editor's note: There are currently no stage 2 flows indicating any action on the call failing (i.e. 3xx, 4xx, 5xx or 6xx 
response. Is VCC action needed at call failure, or is VCC state cleared up in some other manner. If VCC 
state is cleared up on call clearing, is this performed on the CS side transaction, on the IMS side 
transaction, or both. 

Editor's note: There are currently no stage 2 flows indicating any action on the UPDATE or relNVITE requests that 
could negotiate a set of media that cannot be subject to VCC. Is VCC action needed at such relNVITES, 
or is VCC state cleared up in some other manner. If VCC state is cleared up on call clearing, is this 
performed on the CS side transaction, on the IMS side transaction, or both. 

Editor's note: If a 3xx response to INVITE is received, then 24.229 allows entities within the IM CN subsystem to 
redirect the call. This could include entities between the MGCF and the VCC application. Presumably 
such redirection should not be allowed, as this means that the anchor has not completed by being passed 
through from the IMS side. This presumably means that the VCC application must capture 3xx responses 
and do something sensible with them, or else they must get back to the MGCF and cause the call to fail 
back to the user on the CS side. Redirection is not allowed in ISUP except with some national variants, 
but it is allowed within SIP and is caused by the 3xx response. 

Editor's note: The IMRN is available for reuse when the call has been established, event though it is used in the 
To/From header. 
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A.4.5 Signalling flows for origination from CS domain with no 
anchoring 

Figure A.4.5- 1 shows the origination of a voice call that is capable of being subject to VCC, with the anchoring of the 
call in the IM CN subsystem being denied prior to its routeing. The voice call is then continued in the CS domain 
according to standard procedures. 

The anchor decision of such origination calls is subject to operator policy. 

As the originating voice call is not anchored in the IM CN subsystem, domain transfer will not be supported for that 
call. 
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the call is continued in the CS domain according to standard procedures. 



Figure A.4.5-1 : call origination from CS with no anchoring 

The details of the signalling flows are as follows: 

Steps 1 to 4 are identical to the example in subclause A.4.3. 

NOTE 1 : When processing the originating calls for subscriber requiring CAMEL support (step 3), the VMSC 

retrieves the originating CAMEL subscriber information from the VLR that identifies the subscriber as 
having CAMEL services. As a result the gsmSSF of the VMSC triggers a CAMEL activity toward the 
gsmSCF. 

5. Anchor decision 

The VCC application denies the anchoring of the originating call according to the operator policy. In this 
example the called party number is not in the international format and the home IM CN subsystem has no means 
to translate the called party number into a proper routable format. 

6. CAMEL CONTINUE (VCC application to VMSC) 

The VCC application causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL CONTINUE 
message. The CAMEL CONTINUE message contains no parameter. 

NOTE 2: On the receipt of the CAMEL CONTINUE message, the VMSC resumes the processing, continues the 
call in the CS domain according to standard procedures and without any modification of the call 
parameters. 
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A.5 Signalling flows for call termination 
A. 5.1 Introduction 

The signalling flows for call termination demonstrate how a terminating call to a VCC UE is anchored for the purposes 
of a future domain transfer. The following signalling flows are included: 

subclause A. 5. 2 shows a terminating call arriving at the IM CN subsystem, where incoming call routeing has 
directed the call to the IM CN subsystem for anchoring and subsequent delivery of the call to the terminating 
VCC UE; 

subclause A.5. 3 shows a terminating call arriving at the IM CN subsystem, where incoming call routeing has 
directed the call to the IM CN subsystem for anchoring, but subsequently rerouted the call back to the CS 
domain for delivery to the terminating VCC UE; 

subclause A. 5. 4 shows a terminating call arriving at the CS domain, where CAMEL has been used to redirect the 
call to the IM CN subsystem for anchoring and subsequent delivery to the terminating VCC UE; 

subclause A. 5. 5 shows a terminating call arriving at the CS domain, getting routed to, and anchored at the IM 
CN subsystem, and subsequently routed back to the CS domain for delivery to the terminating VCC UE. The call 
routeing from the CS domain to the IM CN subsystem for anchoring is by the HSS(HLR), through internal 
network implementation, obtaining the IMRN for routeing to the IM CN subsystem; 

subclause A.5. 6 shows a terminating call arriving at the IM CN subsystem, where incoming call routeing has 
directed the call to the IM CN subsystem for anchoring, but delivery to the terminating VCC UE in the IM CN 
subsystem has failed, and redelivery is made to the VCC UE in the CS domain; 

subclause A. 5. 7 shows a terminating call arriving at the CS domain, getting routed to, and anchored at the IM 
CN subsystem, and subsequently routed back to the CS domain for delivery to the terminating VCC UE, but 
delivery fails and redelivery is made to the VCC UE using the IM CN subsystem; and 

subclause A.5. 8 shows a terminating call arriving at the CS domain, where CAMEL is used but for which the 
anchoring is denied; the call is continued and delivered in the CS domain. 

A. 5. 2 Signalling flows for termination to the IM CN subsystem 

Figure A.5. 2-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call has 
been routed through the IM CN subsystem and where the called party is terminating in its home IM CN subsystem. 
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Figure A.5.2-1 : Terminating call directed to IM CN subsystem 

The details of the signalHng flows are as follows: 

1 . SIP INVITE request (from the originating IM CN subsystem to intermediate IM CN subsystem entities) 
see example in table A.5.2-1 

In this example the originating UE initiates a voice call through its home IM CN subsystem (homel) with a 
terminating UE which is VCC capable who is in a different network (home2). There is no specific VCC 
information in the SIP INVITE request from the originating UE. 
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The SIP INVITE request is sent by the originating IM CN subsystem to the intermediate IM CN subsystem 
entities. 

Table A.5.2-1 : SIP INVITE request (from the originating IM CN subsystem) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 

Route : <sip : scscf 1 . homel . net ; lr> 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip :pcscf 1 .homel .net; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+S02IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: precondition 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact: <sip: [5555: : aaa :bbb : ccc : ddd] : 1357 ; comp = sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



2. Evaluation of initial filter criteria 

In this example, and by evaluation of the initial filter criteria, the terminating user's S-CSCF routes to the address 
of the VCC application, as the received request is a terminating INVITE request. 

3. SIP INVITE request (intermediate IM CN subsystem entities to VCC application) - see example in 
table A.5.2-3 

The terminating user's S-CSCF adds a set of routeing related headers in order to receive the SIP INVITE request 
back, to route the present request to the VCC application and to maintain itself on the route for all subsequent 
requests. 

The intermediate IM CN subsystem entities forward the INVITE request to the VCC application. 
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Table A.5.2-3: SIP INVITE request (intermediate IM CN subsystem entities to VCC application) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b33 .1, SIP/2. 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 66 

Route : <sip : as .home2 .net;lr>, <sip:scscf2 .home2 .net; lr>;dia-id=6574839201 

Record- Route : <sip:scscf2 .home2 .net;lr>, <sip:scscfl .homel .net ; lr>, <sip ipcscf 1 .homel .net ; lr> 
P-Asserted- Identity : 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; 
orig-ioi="type 3ashomel.net" 
Privacy: 
Supported: 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



4. Session anchoring 

The VCC application decides to perform session anchoring decision based on operator specified criteria. 

5. The VCC application selects the terminating domain 

The VCC application performs domain selection based on operator and user preferences, registration and call 
states; in this example the VCC application selects the terminating IM CN subsystem to terminate the voice call. 

6. SIP INVITE request (VCC appUcation to intermediate IM CN subsystem entities) - see example in 
table A.5.2-6 

The VCC application acts as a rerouteing B2BUA, it initiates the outgoing request and places the called party 
number in the Request-URI and the To header. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

The VCC application sends the SIP INVITE request back to the intermediate IM CN subsystem entities. 
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Table A.5.2-6: SIP INVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP sip:as.home2 .net; branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 

Route: <sip: scscf2 .home2 .net ; lr>;dia-id=6 5 74 8 3 92 01 
Record-Route: <sip: as . home2 . net ; lr> , <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr>, 

<sip :pcscf 1 .homel .net ; lr> 
P-Asserted- Identity : 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: 
Supported: 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



7. Evaluation of initial filter criteria 

In this example, the S-CSCF continues the triggering from the next trigger point. Since no more triggering is 
required in the initial filter criteria, the IM CN subsystem will route the SIP INVITE request to the terminating 
user based on its SIP -URL 

8. SIP INVITE (intermediate IM CN subsystem entities to VCC UE) - see example in table A.5.2-8 

The terminating user's intermediate IM CN subsystem entities forward the SIP INVITE request towards the 
terminating VCC UE. 
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Table A.5.2-8: SIP INVITE request (intermediate IM CN subsystem entities to VCC UE) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .home2 .net :5088;comp=sigcomp;branch=z9hG4bK876tl2 .1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP sip:as.home2 .net; 

branch=z9jG4bK332b23 .3, SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 63 
Record-Route: <sip :pcscf 2 . home2 . net : 5088 ; Ir ; comp=sigcomp> , <sip : scscf 2 .home2 .net ; lr>, <sip: 

as . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 

<sip :pcscf 1 .homel .net; lr> 
P-Asserted- Identity : 
Privacy: 
Supported: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Allow: 

P-Called-Party-ID: 
P-Media-Authorization : 
Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



9. SIP 100 (Trying) response (VCC UE to intermediate IM CN subsystem entities) 

The intermediate VCC UE responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) 
response. 

There is no VCC specific content to this response. 

10, 11, 12 and 13. Reliable exchange of SDP (SIP 183 (Session Progress) response / SIP PRACK request / 
SIP 200 (OK) response / SIP 180 (Ringing) response) 

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the 
IP-C/^, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC 
imposes no restriction on this operation. 

14. SIP 200 (OK) response (UE to intermediate IM CN subsystem entities) 

When the called party answers, the UE sends a SIP 200 (OK) final response to the SIP INVITE request (8) to the 
intermediate IM CN subsystem entities, and starts the media flow(s) for this session. 

There is no VCC specific content to this response. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the VCC application. 
There is no VCC specific content to this response. 
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16. SIP 200 (OK) response (VCC application to intermediate IM CN subsystem entities) 

The VCC application sends the SIP 200 (OK) response back to the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

17. SIP 200 (OK) response (to originating IM CN subsystem) 

The terminating user's intermediate IM CN subsystem entities, forwards the SIP 200 (OK) final response along 
the signalling path back to the calling user through the originating IM CN subsystem. 

There is no VCC specific content to this response. 

18. SIP ACK request (from the originating IM CN subsystem) 

The calling user responds to the SIP 200 (OK) final response with an ACK request through the originating IM 
CN subsystem to the intermediate IM CN subsystem entities of the terminating user. 

There is no VCC specific content to this request. 

19. SIP ACK request (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the VCC application. 
There is no VCC specific content to this request. 

20. SIP ACK request (VCC application to intermediate IM CN subsystem entities) 

The VCC application sends the SIP ACK request back to the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

21. SIP ACK request (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating VCC UE. 
There is no VCC specific content to this request. 

A. 5. 3 Signalling flows for termination to CS domain 

Figure A.5.3-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call has 
been routed through the IM CN subsystem and where the called party is terminating in its home CS domain. 
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Figure A.5.3-1 : Terminating call directed to CS 

The details of the signalling flows are as follows: 

Steps 1 to 4 are identical to the previous example in subclause A. 5. 2. 
5. The VCC application selects the terminating domain 
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The VCC application performs domain selection based on operator and user preferences, registration and call 
states; in this example the VCC application selects the CS domain to terminate the voice call. 

Then the VCC application determines the CS domain Routeing Number (CSRN) and places this number in the 
Request-URI and the To header of the outgoing SIP INVITE request. 

The CSRN is a dynamic routeing number used for routeing into CS domain, i.e. to find the outgoing MGCF and 
then the terminating user's VMSC. 

6. SIP INVITE request (VCC application to intermediate IM CN subsystem entities) - see example in 
table A.5.3-6 

Since the service execution continues as an terminating case, the VCC AS initiates a SIP INVITE request with 
the CSRN as the Request-URI, and sends the SIP INVITE request back to the intermediate IM CN subsystem 
entities. 

The VCC application inserts the Request-URI of the originating UE to the P-Asserted-Identity header in order 
that the Request-URI is known to the destination network in case the SIP INVITE request is forwarded to a 
MGCF. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

The VCC application inserts the original SDP from the originating SIP INVITE request. 
Table A.5.3-6: SIP INVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2. 0/UDP sip:as.home2 .net; branch=z9jG4bK332b23 . 3 , SIP/2 . 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 

Route : <sip : scscf 2 . home2 . net ; lr> ; 
Record-Route: <sip: as . home2 . net ; lr> , <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr>, 

<sip :pcscf 1 .homel .net; lr> 
P-Asserted-Identity : "John Doe" <sip :user2_publicl@home2 .net> <tel : +l-212-555-llll> 
P-Access-Network-Inf o : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: 
From: 

To: <tel:+l-241-555-4444> 
Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



7. SIP INVITE request (intermediate IM CN subsystem entities to MGCF) - see example in table A.5.3-7 
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The intermediate IM CN subsystem entities deliver the SIP INVITE request to the MGCF. In this example, the 
MGCF is reached using a single BGCF. 

Table A.5.3-7: SIP INVITE request (intermediate IM CN subsystem entities to IVIGCF) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP sip : as . home2 . net ; 
branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 63 

Route: <sip :mgcf 2 .home2 .net; lr>; 
Record-Route: <sip : scscf 2 . home2 . net ; lr> , <sip: as .home2 .net ; lr>, <sip : scscf 2 .home2 .net ; lr>, 

<sip:scscfl .homel .net; lr>, <sip :pcscf 1 .homel .net; lr> 
P-Asserted-Identity : "John Doe" <sip :user2_publicl@home2 .net> <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" ; term-ioi="home2 .net" 
Privacy: 
Supported: 
From: 

To: <tel:+l-241-555-4444> 
Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



8a-8d. SIP 183 (Session Progress) response / SIP PRACK request / SIP 200 (OK) response and Reliable 
exchange of SDP 

Reliable exchange of SDP is initiated using the SIP 183 (Session Progress) response and the SIP PRACK request 
and response. 

9. H.248 interaction with the IM-MGW 

When the outgoing MGCF receives a SIP INVITE request with an SDP offer it will first interact with the IM- 
MGW to pick an outgoing channel and determine media capabilities, then can proceed with further SDP 
offer/answer with the originating UE and finally will instruct IM-MGW to reserve the resources necessary for 
the media streams. 

10. ISUP lAM (MGCF to VMSC) 

The MGCF interworks the SIP INVITE request into ISUP and initiates the ISUP lAM carrying the CSRN 
towards the VMSC on which the terminating VCC UE is currently registered (for the interworking ISUP / SIP 
function see 3GPP TS 29.163 [10]). 

11. SETUP message (VMSC to terminating VCC UE) 

The VMSC can derive from the CSRN the details of the called party and then initiates a paging procedure 
towards the terminating VCC UE. 
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After the VCC UE has successfully accessed the network, the VMSC sends to the UE the SETUP message (see 
3GPP TS 24.008 [5]). There is no VCC specific information in the SETUP message. 

12. ALERTING (terminating UE to VMSC) 

For this example, the VMSC allows early local alerting. With the generation of local alerting, ALERTING is 
sent back from the UE to the VMSC. There is no VCC specific information in the ALERTING message. 

13. ISUP ACM (VMSC to MGCP) 

14a-14dl6a-16e. ISUP CFG, SIP 180 (Ringing) response and SIP PRACK request (end to end) 

On receipt of the ALERTING message from the terminating VCC UE, the VMSC and the MGCF exchange 
ISUP to indicate that the called party confirmed the call and did start ringing the end user. 

The VMSC starts resource allocation towards the terminating VCC UE. 

Between VMSC and the IM-MGW resource allocation is also started. 

15. CONNECT message (terminating VCC UE to VMSC) 

When the user answers the call, the terminating VCC UE sends a CONNECT message to the VMSC. After 
sending the CONNECT message, the terminating VCC UE is ready to connect to user plane resources. 

There is no VCC specific information in the CONNECT message. 

16. CONNECT_ACK message (VMSC to terminating VCC UE) 

The VMSC connects up the user plane and return CONNECT_ACK message to the terminating UE. Through 
connect all the way back to originating UE is not initiated. 

There is no VCC specific information in the CONNECT_ACK message. 

17. ISUP ANM (VMSC to MGCF) 

The VMSC having through connected the user plane sends an indication of answer to the MGCF. This is the 
ISUP ANM. 

18. H.248 interaction to start the media flow (MGCF to IM-MGW) 

MGCF initiates a H.248 interaction to make the connection in the IM-MGW bi-directional. 

19. SIP 200 (OK) final response (MGCF to intermediate IM CN subsystem entities) 

Upon the receipt of the ISUP ANM from the MSC, and after the connection of the media flow, the MGCF sends 
the SIP 200 (OK) final response to the received SIP INVITE request (6) toward the IM CN subsystem. The SIP 
200 (OK) response is sent by the MGCF on the behalf the terminating VCC UE over the signalling path to the 
terminating user's S-CSCF. 

There is no VCC specific content to this response. 

20. SIP 200 (OK) final response (from intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) final response to the VCC application. 
There is no VCC specific content to this response. 

21. SIP 200 (OK) final response (from VCC application to intermediate IM CN subsystem entities) 

The SIP 200 (OK) final response is sent back to the terminating user's S-CSCF by the VCC application. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

22. SIP 200 (OK) final response (intermediate IM CN subsystem entities to originating IM CN subsystem) 
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The SIP 200 (OK) response is returned to the originating UE through the originating IM CN subsystem, by the 
terminating user's intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

23. SIP ACK request (from the originating IM CN subsystem to intermediate IM CN subsystem entities) 

The originating UE sends the final acknowledgement to the terminating user's IM CN subsystem through the 
originating IM CN subsystem to the intermediate IM CN subsystem entities of the terminating user. 

There is no VCC specific content to this request. 

24. SIP ACK request (intermediate IM CN subsystem entities to VCC application) 

The terminating user intermediate IM CN subsystem entities forward the SIP ACK request to VCC application. 
There is no VCC specific content to this request. 

25. SIP ACK request (VCC application to intermediate IM CN subsystem entities) 

VCC application sends the SIP ACK request back to terminating user's intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

26. SIP ACK request (intermediate IM CN subsystem entities to MGCF) 

The terminating user's intermediate IM CN subsystem entities forward the SIP ACK request to the MGCF and 
that concludes the terminating call signalling. 

There is no VCC specific content to this request. 

A. 5. 4 Signalling flows for termination directed to IIVI CN 

subsystem (coming from the CS domain) (using CAIVIEL) 

Figure A.5.4-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call is 
coming from CS and where the called party is terminating in its home IM CN subsystem. 

For call termination, the use of CAMEL in the context of VCC is optional. In this example the GMSC support and will 
use terminating CAMEL service logic. 
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HPLMN of the terminating UE 




Figure A.5.4-1 : Terminating call coming from CS domain (using CAMEL) 

The details of the signaUing flows are as follows: 

1 . ISUP lAM (coming from the originating PLMN through the CS domain) 

In this example, a call request (ISUP lAM) makes an entry from the PLMN of the originating user (calling party) 
into the home PLMN of the terminating user (called party). The first entry point of the PLMN of the terminating 
user is the Gateway MSC (GMSC). The call request is a form of an ISUP lAM (Initial Address Message) and 
contains the called party number (MSISDN) 

In this example the MSISDN of the called party is +1-212-123.2222. 

2. MAP Send Routing Information (SRI) (GMSC to HLR) 

On receipt of the incoming call request, the GMSC queries the HLR for routing information. 

3. Retrieval of VCC subscriber information 
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The HLR provides information including the T-CSI information element that contains information configured 
for the VCC subscriber, identifying the subscriber as having terminating CAMEL services. The T-CSI IE also 
includes the gsmSCF address. 

4. MAP Send Routing Information Acknowledgement (SRI ACK) (HLR to GMSC) 

The HLR returns the T-CSI information element to the GMSC in response to the query for routing information 
(SRI). The GMSC now has the address of the gsmSCF. 

5. CAMEL IDP (GMSC to gsmSCF) 

The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP message to the GSM Service 
Control Function (gsmSCF). The CAMEL IDP message contains at least: 

- the calling party number; 
the called parting number; 
the type of call; and 

- information from the T-CSI IE received by the GMSC in the SRI ACK from the HLR. This includes the 
CAMEL service key. 

NOTE: The CAMEL service key can be shared among different CAMEL services, for example, if a VCC 
subscriber is also a prepaid customer. 

6. Invocation of CAMEL services 

The gsmSCF invokes service logic to determine whether the call needs to be rerouted to IM CN subsystem for 
VCC. The CAMEL Service allocates an IMRN and returns it to the gsmSCF. In this example, the VCC 
application (the DTE) also makes the decision that this call will be anchored, based on the type of call and 
operator preferences. 

7. CAMEL CONNECT (gsmSCF to GMSC) 

The gsmSCF to respond to the CAMEL IDP message with a CAMEL CONNECT message containing: 
the Destination Routeing Address set to the IMRN. 
The IMRN is subsequently used to route the call to the VCC application though the IM CN subsystem. 

8. ISUP lAM (VMSC to MGCF) 

The GMSC initiates the CS call towards the MGCF by sending out the ISUP lAM. 

Specifically for this signalling flow, the lAM includes: 

called party number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number), (Number digits = 12415553333)] 

calling party number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number), (Number digits = 121255511 1 1)] 

USI parameter = 3.1 kHz audio 

The called party number parameter represents the IMRN allocated for this call. 

9. H.248 interaction with the IM-MGW 

When the MGCF receives the incoming call from the CS domain it will first interact with the IM-MGW to 
reserve the resources necessary for the media streams and determines the SDP parameter of the outgoing SIP 
INVITE request. 

10. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.5.4-10 

The MGCF initiates a SIP INVITE request, containing an initial SDP towards the I-CSCF in the home IM CN 
subsystem of the terminating VCC user. This routeing is based on the IMRN. 
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The Request-URI contains the IMRN, as obtained from CS networks signalling. 

The P-Asserted-Identity contains the tel URI of the calling party as received from the CS network. 

Based on what is received in the ISUP, the MGCF identifies the incoming call as speech call and includes in the 
SDP a preconfigured set of codecs supported by the MGW (for more details see 3GPP TS 29.163 [10]). 

Table A.5.4-10: SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf2 .homel.net;branch=z9hG4bK779s24 . 

Max- Forwards : 7 

Route : <sip : icscf 2 . home2 . net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="homel .net" 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel 

Contact: <sip :mgcf 2 .home2 .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; mode- change -period=2 

a = r tpmap :96 telephone- event 

a=maxpt ime : 2 



1 1 . SIP INVITE request (intermediate IM CN subsystem entities to VCC application) - see example in 
table A.5.4-11 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route requests to this PSI to 
the VCC application. The SIP INVITE request is therefore forwarded to the VCC application. 
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Table A.5.4-11 : SIP INVITE request (intermediate IIUI CN subsystem entities to VCC application) 



INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf2 .home2 .net;branch=z9hG4bK779s24 . 0, SIP/2. 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 69 
Route: <sip :as .homel2 .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="type 
3homel .net" ; orig-ioi="homel .net" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



12. SIP 100 (Trying) response (VCC application intermediate to IM CN subsystem entities) 

There is no VCC specific content to this response. 

13. Session anchoring and terminating domain selection 

Unless anchoring was already performed (e.g. at step 3), the VCC application (DTF) decides here that this call 
will be anchored, based on the type of call and operator preferences. 

The VCC application (CSAF) retrieves the original called party number and calling party number associated 
with the IMRN and performs domain selection based on operator and user preferences, registration and call 
states; in this example the VCC application selects the IM CN subsystem to terminate the call. 

The VCC application acts as a routeing B2BUA, thus it initiates the outgoing request and places the called party 
number in the Request-URl and the To header. 

14. SIP INVITE request (VCC application to intermediate IM CN subsystem entities) - see example in 
table A.5.4-14 

The VCC application forwards the SIP INVITE request to the S-CSCF serving the terminating user within the 
IM CN subsystem. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

The VCC application sets the value of the Contact header with the address of the VCC application that will 
provide the transfer functionality needed to support VCC. 

In the case where the Request-URI of the SIP INVITE request contains a tel-URL, the S-CSCF (next hop) will 
have to translate to a globally routeable SIP-URI before applying it as Request-URI of the outgoing SIP INVITE 
request toward the terminating user. 
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Table A.5.4-14: SIP INVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP as.home2.net; branch=z9hG4bK779s24 . , SIP/2. 0/UDP 
mgcf2 .home2.net;branch=z9hG4bK779s24 . 0, SIP/2 . 0/UDP 
icscf2 .home2 .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 68 

Route : <sip : s-cscf . home2 . net ; lr> 
P-Asserted- Identity : 
P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; 

orig-ioi="Type 3homel.net" 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call -ID: dcl4bltlOb3teghmlk5 01444 
Cseq: 

Supported: 

Contact: <sip : as .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



15. Evaluation of initial filter criteria 

In this example, the S-CSCF continues the triggering from the next trigger point. Since no more triggering is 
required in the initial filter criteria, the IM CN subsystem will route the SIP INVITE request to the terminating 
user based on its SIP URI. 

16. SIP INVITE request (intermediate IM CN subsystem entities to VCC UE) - see example in table A.5.4-16 

The terminating user's intermediate IM CN subsystem entities forward the SIP INVITE request towards the 
terminating VCC UE. 
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Table A.5.4-16: SIP INVITE request (intermediate IIUI CN subsystem entities to VCC UE) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .home2 .net :5088;comp=sigcomp;branch=z9hG4bK876tl2 .1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z8 7 . 1, SIP/2 . 0/UDP sip:as.home2 .net; 

branch=z9jG4bK332b23 .3, SIP/2 . 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

icscf2.home2.net;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 

mgcf2 .home2 .net ;branch=z9hG4bK332b23 . 1, 
Max- Forwards : 6 7 
Record-Route : 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Allow: 

P-Called-Party-ID: 
P-Media-Authorization : 
Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



17. SIP 100 (Trying) response (VCC UE to intermediate IM CN subsystem entities) 

The VCC UE responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

18. Reliable exchange of SDP and Ringing/Alerting signalling 

The terminating UE accepts the session request and reserves an IP-CAN bearer for the message session media 
component. 

SDP offer/answer exchange can happen between the called party and the MGCP. 

End users signals end to end ringing/alerting 

19. SIP 200 (OK) response (UE to intermediate IM CN subsystem entities) 

When the called party answers, the UE sends a SIP 200 (OK) final response to the SIP INVITE request (16) to 
the intermediate IM CN subsystem entities, and starts the media flow(s) for this session. 

There is no VCC specific content to this response. 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the VCC application. 
There is no VCC specific content to this response. 

21. SIP 200 (OK) response (VCC application to intermediate IM CN subsystem entities) 

The VCC application sends the SIP 200 (OK) response back to the intermediate IM CN subsystem entities. 
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The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

22. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The terminating user's intermediate IM CN subsystem entities forward the SIP 200 (OK) final response to the 
MGCF. 

There is no VCC specific content to this response. 

23. ISUP ANM (MGCF to GMSC) 

The MGCF indicates the call has been answered back to the GMSC with an ISUP ANM. 
There is no VCC specific content in this message. 

24. ISUP ANM (GMSC to the originating user's PLMN) 

The GMSC forwards the ISUP ANM to the originating user's PLMN. 
There is no VCC specific content in this message. 

25. SIP ACK request (MGCF to intermediate IM CN subsystem entities) 

Having indicated the call has been answered toward the originating user, the MGCF acknowledges the SIP 200 
(OK) response with the SIP ACK request to the intermediate IM CN subsystem entities. 

There is no VCC specific content to this request. 

26 H.248 interaction to start the media flow (MGCF) 

MGCF initiates a H.248 interaction to make the connection in the IM-MGW bi-directional. 

27. SIP ACK request (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the VCC application. 
There is no VCC specific content to this request. 

28. SIP ACK request (VCC application to intermediate IM CN subsystem entities) 

The VCC application sends the SIP ACK request back to the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

29. SIP ACK request (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the VCC UE. 
There is no VCC specific content to this request. 

A. 5. 5 Signalling flow for termination directed to CS domain 
(coming from the CS domain) 

Figure A.5.5-1 illustrate an example signalling flow of a voice call to a VCC UE coming in through the CS domain, 
getting anchored to the VCC application within the IM subsystem and then delivered to the terminating VCC UE 
through the CS domain. 

In this example, the terminating UE is in his/her HPLMN. 
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In this example, this PLMN does not utilise terminating CAMEL service logic. Rather this example illustrates 
HSS(HLR) directed call diversion to the IM CN subsystem where the HSS(HLR), through internal network 
implementation, can obtain the IMRN. 
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Figure A.5.5-1 : Terminating call coming in through CS domain and delivered through the CS domain 
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Figure A.5.5-1 : Terminating call coming in through CS domain and delivered through the CS domain (continued) 
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The details of the signalling flows are as follows: 

1 . ISUP lAM (coming into this PLMN through the CS domain) 

A call request makes an entry into this PLMN. First entry point is the GMSC. 
This Initial Address Message contains the MSISDN of the called party 
In this example the MSISDN is +1-212-123.2222. 

2. MAP SEND_ROUTING_INFORMATION (GMSC to HSS/HLR) 

GMSC makes a query to the HSS/HLR for routeing information for onward routeing of the incoming call 

request. 

This GMSC query SEND_ROUTING_INFORMATION contain the MSISDN of the called party. 

3. Derivation of IMRN 

Internal network actions - not indicated here as those actions are implementation and network dependent - are 
taken. The result is that (for this example) a decision is make to route the call further onwards into the IM CN 

subsystem. 

In particular an IMRN is obtained in these internal network actions. 

For this example the derived IMRN is +1-212-123-3333. 

NOTE 1 : It is an implementation and network option whether the derivation of the IMRN takes in the decision to 
anchor the call to the VCC application. 

4. MAP SEND_ROUTING_INFORMATION_RESULT (HSS/HLR to GMSC) 

The HSS/HLR replies to the query by GMSC with the SEND_ROUTING_INFORMATION_RESULT 
providing with it the IMRN 

5. ISUP lAM (GMSC to MGCFa) 

GMSC sends out lAM (IMRN). The IMRN is that which will direct the routeing of the lAM to the MGCF. 
In this example, the lAM (IMRN = +1-241-555-3333) is routed to MGCFa. 

6. SIP INVITE request (MGCFa towards the VCC appUcation through the intermediate IM CN subsystem 
entities) - see example in table A.5.5-6 

The MGCF interworks the lAM (IMRN) into the appropriate SIP message and initiates the SIP INVITE request 
towards the VCC application via the intermediate IM CN subsystem entities. 
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Table A.5.5-6: SIP INVITE request (MGCFa towards the VCC application through the intermediate IM 

CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: 10 Orel 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



7. H.248 interaction witli the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

8. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MGCFa) 

The intermediate IM CN subsystem entities respond to the MGCFa with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

9. SIP INVITE request (intermediate IM CN subsystem entities to the VCC appUcation) - see example in 
table A.5.5-8 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the VCC 
application. In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, 
there is no IBCF before the I-CSCF and no intermediate entities Record-Route the request. 
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Table A.5.5-9: SIP INVITE request (intermediate IM CN subsystem entities to the VCC application) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 0, SIP/2. 0/UDP 

icscf l_s .homel .net ;branch=z9hG4bK312a32 . 1 
Max-Forwards: 69 
Route: <sip : as .homel .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=type 
3homel.net; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. SIP 100 (Trying) response (VCC application to intermediate IM CN subsystem entities) 

The VCC application responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

1 1 . Retrieval of the called party details from IMRN 

From the IMRN the VCC application retrieves the called party details. This retrieval process is implementation 
dependent. 

NOTE 2: It is a further implementation dependent option whether the decision to anchor the call such that VCC 
feature can be made available to the called party is made at this step. 

12. Domain selection 

For this example, a decision has been made (either at Step 3 or step 1 1) to anchor the call such that VCC through 
domain transfer can be performed. A decision has now to be made on which domain the terminating call is to be 
delivered. This decision is implementation specific. 

For this example, the decision is to deliver the terminating call through the CS domain. 

13. Derivation of the CSRN 

Having made the decision of delivering the call (for this example) in the CS domain, the VCC application 
derives the CSRN. The CSRN will allow the call to be routed further into the CS domain. The derivation of the 
CSRN is implementation specific. 

For this example, the CSRN = +1-241-555-4444 

14. SIP INVITE request (VCC appUcation to intermediate IM CN subsystem entities) - see example in 
table A.5.5-14 
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Having derived the CSRN, the VCC application now acts a routeing B2BUA and initiates a SIP INVITE request 
with the CSRN as the Request-URL The SIP INVITE request is sent back to the intermediate IM CN subsystem 
entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

Table A.5.5-14: SIP INVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2 .0/UDP;branch=z9hG4bK312a32 .1 

Max- Forwards : 6 8 

Route : <sip : s-cscf . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltl0b3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip : as .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



15. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities respond to the VCC application with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

16. SIP INVITE request (intermediate IM CN subsystem entities to MGCFb) 

The intermediate IM CN subsystem delivers the SIP INVITE request to the MGCF. In this example this is a 
different MCGF than the the MGCF which receives the ISUP lAM carrying the IMRN. In this example the SIP 
INVITE request with the CSRN is directed to MGCFb. 

This example signalling flow involving different MGCF further illustrates a pragmatic example of call 
distribution to different MGCFs of one network. 

17. SIP 100 (Trying) response (MGCFb to intermediate IM CN subsystem entities) 

The MGCF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

18. ISUP lAM (MGCFb to VMSC) 

The MGCF interworks the SIP INVITE request to the ISUP and initiates the ISUP lAM carrying the CSRN 
towards the VMSC. 

19. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 
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20. Retrieval of the called party details from CSRN 

The VMSC can from the CSRN retrieve the details of the called party and with that initiates a paging procedure 
towards the terminating UE. 

21. SETUP message (VMSC to terminating VCC UE) 

After the UE has successfully accessed the network, the VMSC sends to the VCC UE the 24.008 SETUP 
message. 

There is no VCC specific content in this message. 

For this example, the VMSC allows early local alerting. 

22. CALL_CONFIRM message (Terminating VCC UE to VMSC) 

The terminating UE acknowledges and confirms acceptance of the incoming call by sending a CONFIRM back 
to the VMSC. There is no VCC specific content in this message. 

23. ALERTING message (terminating VCC UE to VMSC) 

For this example, the VMSC allows early local alerting. With the generation of local alerting, an ALERTING 
message is sent back from the VCC UE to the VMSC. There is no VCC specific content in this message. 

24. ACM, CPG, SIP 180 (Ringing) response and SIP PRACK request (VMSC to MGCFb through IM CN 
subsystem to the originating end) 

On receipt of the ALERTING message from the terminating VCC UE, the VMSC, MGCF, IM CN subsystem 
and the originating UE exchange ISUP and SIP signalling to indicate that the called party confirmed the call and 
did start ringing the end user. 

25. Resource allocation (MSC to terminating VCC UE and VMSC) 

The VMSC starts resource allocation towards the terminating VCC UE. 

26. Resource allocation (VMSC to MGWb) 

Between VMSC and the IM-MGW resource allocation is also started. 

27. CONNECT message (terminating VCC UE to VMSC) 

When the user answers the call, the terminating VCC UE sends a CONNECT message to the VMSC. After 
sending the CONNECT message, the terminating VCC UE is ready to connect to user plane resources. 

There is no VCC specific content in this message. 

28. CONNECT_ACK message (VMSC to terminating VCC UE) 

VMSC connects up the user plane and return a CONNECT_ACKNOWLEDGE message to the terminating VCC 
UE. 

There is no VCC specific content in this message. 

Through connect all the way back to originating UE is not initiated. 

29. ISUP ANM (VMSC to MGCFb) 

The VMSC having through connected the user plane sends an indication of answer to the MGCFTj. This is the 
ISUP ANM. 

There is no VCC specific content in this message. 

30. SIP 200 (OK) response (MGCFb to intermediate IM CN subsystem entities meant for VCC application) 

Upon the receipt of the ANM from the VMSC, and after the connection of the media flow, the MGCFb sends the 
SIP 200 (OK) final response to the received SIP INVITE request ( in step 15) back to the VCC application via 
the intermediate IM CN subsystem entities. 
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There is no VCC specific content to this response. 

3 1 . SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 

The SIP 200 (OK) final response is forwarded to the VCC apphcation, by the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this response. 

32. SIP 200 (OK) response (VCC application to intermediate IM CN subsystem entities meant for MGCFa) 

The VCC application sends the SIP 200 (OK) final response back to the MGCFa relating to the received SIP 
INVITE request ( in step 8). This is sent through the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

33. SIP 200 (OK) response (intermediate IM CN subsystem entities delivering to MGCFa) 

The SIP 200 (OK) final response is forwarded to the MGCFa by the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 

34. ISUP ANM (MGCFa to GMSC) 

The MGCF indicates call has been answered back to the GMSC with ISUP ANM. 
There is no VCC specific content in this message. 

35. SIP ACK request (MGCFa to intermediate IM CN subsystem entities meant for VCC application) 

Having indicate the call has been answered to the GMSC, MGCFa acknowledges the SIP 200 (OK) response 
with the SIP ACK request to the VCC application. This is sent through the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this request. 

36. ISUP ANM (GMSC towards originating end) 

GMSC sends an indication of call answer towards the originating side. 

37. SIP ACK request (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities deliver the SIP ACK request to the VCC application. 
There is no VCC specific content to this request. 

38. SIP ACK request (VCC application to intermediate IM CN subsystem entities meant for MGCFb) 

VCC application in turn acknowledges the MGCFb with the SIP ACK request. This is sent through the 
intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

39. SIP ACK request (intermediate IM CN subsystem entities to MGCFb) 

The SIP ACK request is delivered to the MGCFTj by the intermediate IM CN subsystem entities. 
There is no VCC specific content to this request. 
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A. 5. 6 Signalling flows with call termination delivery attempt failure 
to the IIVI CN subsystem 

Figure A.5.6-1 shows the termination of a call that is capable of being subject to VCC, where the call delivery attempt 
to the IM CN subsystem fails. In this example and following information available at the VCC application, the call 
termination is re-attempted on the CS domain, 2°'' domain available. 

In this example, when the VCC Application receives the indication that delivery of the terminating call through the 
selected IM CN subsystem cannot be completed, the VCC application performs an implementation option to attempt 
delivery of the terminating call through the CS domain. Use of this implementation option depends on operator policies. 
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The termination of the call can proceed toward the CS domain as described in "A.5.3. Signalling flows for termination of the CS domain" starting 

from step 1 0. 



Figure A.5.6-1 : Call termination delivery attempt failure to the IM CN subsystem 

The details of the signalling flows are as follows: 

Steps 1 to 7 are identical to the example in subclause A. 5. 2. 

8. User unreachable 

The delivery of the call fails due to an error detected in the termination procedure. This could be due to, for 
example, destination busy (error code 486), destination service denied (error code 403), destination currently out 
of coverage (error code 480), or some other error. In this example the intermediate IM CN subsystem returns SIP 
480 (Temporarily unavailable) response to the VCC application. 

9. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to VCC 
application) - see example in table A.5.6-9 

The intermediate IM CN subsystem returns SIP 480 (Temporarily Unavailable) response to the VCC application. 
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Table A.5.6-9: SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to VCC 

application) 



SIP/2.0 480 Temporarily unavailable 


Via: SIP/2. 0/UDP sip: as. home2.net; branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP 


scscf2 .home2 .net ;branch=z9hG4bK332b23 . 1, pcscf2 .home2 .net ;branch=z9hG4bK431h23 . 1, 


SIP/2. 0/UDP 


From: 


To: 


Call-ID: 


Cseq: 


Retry-After: 3600 


Content -Length: 



10. Domain Selection (re-attempt) 

In this example the VCC user has been simultaneously registered in IM CN subsystem and in the CS domain 
(CS attached). This information is known to the VCC application, and after the first attempt and failure to deliver 
the terminated call in the IM CN subsystem, the VCC application re-attempts on the second domain available to 
the terminated user i.e. the CS domain. 

NOTE 1 : The choice for the VCC application to re-attempt the call termination on the second domain available 
following a failure on the first domain is subject to operator policy. 

The VCC application determines the CSRN. The CSRN will allow the call to be routed further into the CS 
domain. In this example the CSRN = H-1-241-555-4444 

NOTE 2: it is an implementation option as how the VCC application determines the CSRN. 

11. SIP INVITE request (VCC application to intermediate IM CN subsystem entities) - see example in 
table A.5.6-11 

The VCC application sends SIP INVITE request with the CSRN as the Request-URI to the intermediate IM CN 
subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

The VCC application inserts the Request-URI of the originating user to the P-Asserted-Identity header in order 
that the identity of the originating user becomes known to the destination network for the case the SIP INVITE is 
forwarded to a MGCF. 

The VCC application inserts the original SDP from the originating SIP INVITE request. 
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Table A.5.6-11 : SIP INVITE request (VCC application to intermediate IIVI CN subsystem entities) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2. 0/UDP sip:as.home2 .net; branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 

Route : <sip : scscf 2 . home2 . net ; lr> ; 
Record-Route: <sip: as . home2 . net ; lr> , <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr>, 

<sip :pcscf 1 .homel .net; lr> 
P-Asserted-Identity : "John Doe" <sip :user2_publicl@home2 .net> <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: 
From: 

To: <tel:+l-241-555-4444> 
Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



The termination of the call can proceed toward the CS domain as described in the subclause A.5.3 starting from the 
step 10. 

A. 5. 7 Signalling flow for termination directed to CS domain, 
unsuccessful delivery, redirect to IIVI CN Subsystem 

Figure A.5.7-1 illustrate an example signalling flow of a voice call to a VCC UE coming in through the CS domain. 
Upon being anchored in the IM CN subsystem the decision on domain selection resulted in the CS domain being the 
selected domain for call delivery. However, the terminating call cannot be completed and in this example flow the 
domain selection function of the VCC application is consulted again. The IM CN subsystem is subsequently selected to 
complete the terminating call. 

In this example, the terminating UE is in his/her HPLMN. 

In this example, this PLMN does not utilise terminating CAMEL service logic. Rather this example illustrates 
HSS(HLR) directed call diversion to the IM CN subsystem where the HSS(HLR), through internal network 
implementation, can obtain the IMRN 

In this example, the failure to complete the terminating call establishment is due to the VMSC having initiated the 
paging procedure fails to get a respond from the UE in the course of normal and extended paging. 

In this example, when the MSC fails to complete the terminating call establishment, the MSC shall return the ISUP 
RELEASE message with an appropriate cause value to the MGCF that will allow the MGCF to map to an appropriate 
SIP method and indication that indicates that the user is currently not reachable. 
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Editor's note: It is FFS what cause value the ISUP RELEASE shall carry. It is also FFS which exact SIP 4xx 
message MGCP shall send. 

Editor's note: The determination of the ISUP RELEASE cause values and which SIP 4xx message MGCF sends can 
require changes to TS 29.163 

In this example, when the VCC Application receives the indication that deUvery of the terminating call through the 
selected CS domain cannot be completed, the VCC application performs an implementation option to attempt delivery 
of the terminating call through the IM CN Subsystem. This implementation option further interacts with operator 
dependent policies. 
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Figure A.5.7-1 : Terminating call coming in through CS domain, CS domain selected for call delivery, call delivery unsuccessful, domain for call 

delivery reselected 
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35. signalling sequence here on is the same as given in subclause A.5.4, Figure A.5.4-1 message 17 onwards. This results in 
the call completion to the terminating UE and completes the establishment of the CS and IMS bearers 
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Figure A.5.7-1 : Terminating call coming in through CS domain, CS domain selected for call delivery, call delivery unsuccessful, domain for call 

delivery reselected (continued) 
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The details of the signalling flows are as follows: 

1 . ISUP lAM (coming into this PLMN through the CS domain) 

A call request makes an entry into this PLMN. First entry point is the GMSC. This ISUP lAM contains the 
MSISDN of the called party. 

In this example the MSISDN is +1-212-123-2222. 

2. MAP SEND_ROUTING_INFORMATION (GMSC to HSS/HLR) 

GMSC makes a query to the HSS/HLR for routeing information for onward routeing of the incoming call 
request. This GMSC query SEND_ROUTING_INFORMATION contain the MSISDN of the called party. 

3. Derivation of IMRN 

Internal network actions - not indicated here as those actions are implementation and network dependent - are 
taken. The result is that (for this example) a decision is make to route the call further onwards into the IM CN 

subsystem. 

In particular an IMRN is obtained in these internal network actions. 

For this example the derived IMRN is +1-241-555-3333. 

NOTE 1 : It is an implementation and network option whether the derivation of the IMRN takes in the decision to 
anchor the call to the VCC application. 

4. MAP SEND_ROUTING_INFORMATION_RESULT (HSS/HLR to GMSC) 

The HSS/HLR replies to the query by GMSC with the SEND_ROUTING_INFORMATION_RESULT 
providing with it the IMRN 

5. ISUP lAM (GMSC to MGCFa) 

GMSC sends out lAM (IMRN). The IMRN is that which will direct the routeing of the lAM to the MGCF. In 
this example, the lAM (IMRN = +1-241-555-3333) is routed to MGCFa. 

6. H.248 interaction with the IM-MGW 

When the MGCF receives the incoming call from the CS domain it will interact with the IM-MGW to reserve 
the resources necessary for the media streams and determines the SDP parameter of the outgoing SIP INVITE 
request. 

7. SIP INVITE (MGCFa towards the VCC application through the intermediate IM CN subsystem) - see 
example in table A.5.7-7 

The MGCF interworks the lAM (IMRN) into the appropriate SIP message and initiates the SIP INVITE towards 
the VCC application via the intermediate IM CN subsystem entities. 

The MGCF interacts with the MGW for the necessary resource allocation. 
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Table A.5.7-7: INVITE request 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel:+l-212-5 55-llll>;tag=17182 8 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



8. SIP 100 (Trying) response (Intermediate IM CN subsystem entities to MGCFa) 

The intermediate IM CN subsystem entities respond to MGCFa with a SIP 100 (Trying) response. 
There is no VCC specific content to this request. 

9. SIP INVITE request (intermediate IM CN subsystem entities to the VCC application) - see example in 
table A.5.7-9 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the VCC 
application. In this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, 
there is no IBCF before the I-CSCF and no intermediate entities Record-Route the request. 
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Table A.5.7-9: SIP INVITE request (intermediate IM CN subsystem entities to the VCC application) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP icscfl_s.homel.net;branch=z9hG4bK312a32 .1, 

SIP/2 . 0/UDP mgcf 1 .homel .net;branch=z9hG4bK779s24 . 

Max- Forwards : 69 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



10. SIP 100 (Trying) response (VCC application to intermediate IM CN subsystem entities) 

The VCC application responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

1 1 . Retrieval of the called party details from IMRN 

From the IMRN the VCC application retrieves the called party details. This retrieval process is implementation 
dependent. 

NOTE 2: It is a further implementation dependent option whether the decision to anchor the call such that VCC 
feature can be made available to the called party is made at this step. 

12. Domain selection 

For this example, a decision has been made (either at Step 3 or step 10) to anchor the call such that VCC through 
domain transfer can be performed. A decision has now to be made on which domain the terminating call is to be 
delivered. This decision is implementation specific. 

For this example, the decision is to deliver the terminating call through the CS domain. 

13. Derivation of the CSRN 

Having made the decision of delivering the call (for this example) in the CS domain, the VCC application 
derives the CSRN. The CSRN will allow the call to be routed further into the CS domain. The derivation of the 
CSRN is implementation specific. 

For this example, the CSRN = +1-241-555-4444 

14. SIP INVITE (VCC application towards the MGCFb through the intermediate IM CN subsystem entities) 
- see example in table A.5.7-14 

Having derived the CSRN, the VCC application now acts a B2BUA and initiates an INVITE with the CSRN as 
the request URI, and sends it back to the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.5.7-14: INVITE request 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2 .0/UDP;branch=z9hG4bK312a32 .1 

Max-Forwards: 68 

Route : <sip : s-cscf . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltlOb3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip : as .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



15. Evaluation of initial Filter Criteria 

In this example there are no further matches of Service Point Triggers that cause further routeing to other 
Application Server. 

16. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities respond to the VCC application with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

17. SIP INVITE request (intermediate IM CN subsystem entities to MGCFb) 

The ntermediate IM CN subsystem entities deliver the SIP INVITE request to the MGCF. In this example this is 
a different MCGF than the the MGCF which receives the ISUP 1AM carrying the IMRN. In this example the SIP 
INVITE request with the CSRN is directed to MGCFb. 

This example flow involving different MGCF further illustrates a pragmatic example of call distribution to 
different MGCFs of one network. 

18. SIP 100 (Trying) response (MGCFb to intermediate IM CN subsystem entities) 

The MGCFb responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

19. ISUP lAM (MGCFb to VMSC) 

The MGCF interworks the SIP INVITE request to the ISUP and initiates the ISUP lAM carrying the CSRN 
towards the VMSC. 

20. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

21 . Retrieval of the called party details from CSRN 
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The VMSC can from the CSRN retrieve the details of the called party and with that initiates a paging procedure 
towards the terminating UE. 

22. ISUP ACM (VMSC to MGCFb) 

With the determination that the address is complete and that the terminating UE details are valid the VMSC 
returns to the MGCF the ISUP ACM message. There is no VCC specific content in this message. 

23a-f. Propagation of indication of address complete back to calling side 

The SIP endpoints complete SDP offer/answer procedures, and any exchange of alerting indication, in 
accordance with standard basic call procedures. VCC imposes no restriction on this operation. 

MGCFa then sends the ISUP ACM back to the originating side thi'ough the GMSC. 

24. VMSC concludes that terminating call attempt has failed 

MSC conclude that paging procedure has failed when mobile did not respond to normal or extended paging. 

25. ISUP REL (VMSC to MGCFb) 

VMSC concluding that terminating call is unsuccessful, provides a ISUP REL to the MGCFb. The ISUP REL 
will carry the reason for release indicating that the terminating call attempt is unsuccessful. 

Editor's note: It is FFS what the exact cause the ISUP RELEASE shall carry. 

26. H.248 interaction for bearer release 

MGCFb interacts with MGWb to release the allocated resources which will now not be needed. 

27. ISUP RLC (MGCFb to VMSC) 

MGCFb having interacted with MGWb to release the resources return ISUP RLC to indicate that the MGCFb 
has now completed its release. 

28. SIP 4xx (MGCFb towards VCC application through the intermediate IM CN subsystem entities) 

MGCFb indicate the release back towards the originator - in this case the VCC application. This the MGCFb 
does by interworking the ISUP message to a SIP 4xx response sent to the intermediate IM CN subsystem 
entities. 

Editor's note: It is FFS what the exact 4xx message the MGCF will send. 

29. SIP 4xx (Intermediate IM CN subsystem to VCC appUcation) 

The SIP 4xx is forwarded to the VCC application by the intermediate IM CN subsystem entities. 

30. VCC applications determines next cause of action 

In this example, the VCC application through an implementation option of the domain selection function decides 
to re-attempt delivery of the terminating call in the IM CN subsystem. This implementation option is further 
driven by an operator policy that will influence the decision of whether to re-attempt delivering the terminating 
call and limit the number of re-attempts to guard against unnecessary and endless looping. 

3 1 . SIP INVITE request (VCC appUcation to terminating UE through the intermediate IM CN subsystem 
entities) - see example in table A.5.7-31 

The VCC application sends the SIP INVITE request to the intermediate IM CN subsystem entities serving the 
terminating user within the IM CN subsystem. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

The VCC application sets the value of the Contact header with the address of the VCC application that will 
provide the transfer functionality needed to support VCC. 
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In the case where the Request-URI of the SIP INVITE request contains a tel-URL, the S-CSCF (next hop) will 
have to translate to a globally routeable SIP-URI before applying it as Request-URI of the outgoing SIP INVITE 
request toward the terminating user. 

Table A.5.7-31 : SIP INVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP as.homel.net [5555 : : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : 

Record-Route : <sip : as . homel . net ; lr> 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 

P-Access-Network-Info : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

Sashomel .net" 
Privacy: none 
Supported: precondition 

From: <sip :userl_publicl®homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] : 1357;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Contact header: The Contact header represents the contact of the VCC application. 

32. Evaluation of initial filter criteria 

To the S-CSCF that is managing the terminating UE, this will be seen as a new call, the first INVITE to the 
terminating UE. As part of its filter criteria, care is now taken that this INVITE will not be routed back to the 
VCC application for anchoring decision and further domain selection. Due considerations are given to avoid 
endless looping. 

Editor's note: How the S-CSCF identifies or differentiates this new INVITE is not to be sent back to VCC 
application is FFS. 

33. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities respond to the VCC application with a SIP 100 (Trying) response. 
There is no VCC specific content in this response. 

34. SIP INVITE (intermediate IM CN subsystem entities to VCC UE) - see example in table A.5.7-34 

The terminating user's intermediate IM CN subsystem entities will send the SIP INVITE request towards the 
terminating VCC UE. 
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Table A.5.7-34: SIP INVITE request (intermediate IIUI CN subsystem entities to VCC UE) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2 . 0/UDP pcscf 1 .homel .net : 50 88 ; comp=sigcomp;branch=z9hG4bK8 76tl2 . 1, 

SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK764z87.1, 

SIP/2. 0/UDP sip: as. homel. net; branch=z9jG4bK332b23 . 3 
Max- Forwards : 6 8 
Route : 

Record-Route: < pcscf 1 .homel .net>, < scscfl .homel .net>, <sip : as .homel .net ; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: precondition 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



35a. ISUP ACM (VMSC to MGCFb) 

35b. ISUP lAM 

35c. Signalling flows completing SIP call to terminating UE and interworked back to originating side 

The signalling flows here on till the completion of the call and utilisation of the media resources are in accordance with 
step 17 through to step 28 of subclause A.5.4, and Figure A.5.4-1. 

A. 5. 8 Signalling flows for termination from CS domain with no 
anchoring (using CAIVIEL) 

Figure A.5.8-1 shows the termination of a voice call that is capable of being subject to VCC, with the anchoring of the 
call in the IM CN subsystem being denied prior to its routeing. The voice call is then delivered in the CS domain 
according to standard procedures. 

The anchor decision of such terminated calls is subject to operator policy. 

As the terminated voice call is not anchored in the IM CN subsystem, domain transfer will not be supported for that 
call. 

NOTE 1 : For call termination, the use of C/VMEL in the context of VCC is optional. In this example the GMSC 
support and will use terminating CAMEL service logic. 
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the call is continued and delivered in the CS domain according to standard procedures . 



Figure A.5.8-1 : call termination from CS domain with no anchoring 

The details of the signalhng flows are as follows: 

Steps 1, 2, 3, 4 and 5 are identical to the example in subclause A.5.4. 

NOTE 2: When processing terminating calls, the GMSC interrogates the HLR. In this example the GMSC indicates 
its support for CAMEL. The GMSC receives back from the HLR the terminating CAMEL subscriber 
information. As a result the gsmSSF of the GMSC triggers a CAMEL activity toward the gsmSCF. 

6. Anchor decision 

The VCC application denies the anchoring of the terminating call according to the operator policy. In this 
example the VCC application is unable to allocate a new IMRN for this call i.e. insufficient IMRN. 

7. CAMEL CONTINUE (VCC application to GMSC) 

The VCC application causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL CONTINUE 
message. The CAMEL CONTINUE message contains no parameter. 

8. 9 and 10. Further interrogation with the HLR (GMSC to HLR) 

Following standard terminating call procedure for CAMEL subscribers, on the receipt of the CAMEL 
CONTINUE message, the GMSC interrogates the HLR again by including a parameter that indicates the 
suppression of CAMEL handling. On the receipt of the answer from the HLR, the GMSC resumes the processing 
and continues the call in the CS domain according to standard procedures. 



A. 6 Signalling flows for CS domain to IM CN subsystem 
transfer 

A. 6.1 Introduction 

The signalling flows for CS domain to IM CN subsystem transfer demonstrate how a VCC UE transfers the call from 
the CS domain to the IM CN subsystem. The following signalling flows are included: 

subclause A.6.2 shows the successful transfer for a call, currently in the CS domain, and which is transferred to 
the IM CN subsystem; and 
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subclause A. 6. 3 shows the case where a transfer request for a call, currently in the CS domain, cannot be 
complied with at the VCC application due to the failure to match the request with an anchored call for that user. 

A. 6. 2 Signalling flows for CS domain to IIVI CN subsystem transfer 

Figure A.6.2-1 shows the signalling flows for a domain transfer of the access leg from the CS domain to the IM CN 
subsystem. This example assumes that the VCC user is currently registered in the IM CN subsystem. If the VCC user is 
not currently registered in the IM CN subsystem prior to determination of domain transfer, it is required that registration 
procedures are initiated before updating the access leg. 
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Figure A.6.2-1 : CS domain to IIVI CN subsystem transfer 

The details of the signalhng flows are as follows: 
1 . CS bearer (VCC UE to MGW) 

The call is ongoing in the CS domain. 



Remote end 
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2. IP bearer (MGW to remote end) 

IP bearer over which the voice call is transmitted toward to the remote end. 

3. Determination of domain transfer 

As a result of changes in radio conditions or availability of IM services via IPCAN, the VCC UE decides that the 
ongoing call in the CS domain will be transferred to the IM CN subsystem. 

4. SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) - see example in table A.6.2-4 

The VCC UE sends a SIP INVITE request to initiate session set up in the IM CN subsystem. The SIP INVITE 
request is sent from the VCC UE to the home S-CSCF (S-CSCF#1) via P-CSCF#1. The Request-URI header is 
set to the VCC application PSI. 

Table A.6.2-4: SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) 



INVITE sip: domain.xfer@cccfl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp = sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net; lr> 

P-Preferred-Identity: <tel: +l-212-555-llll> 

P-Access-Network-Info: IEEE-WLAN-802 . lib; 

Privacy: none 

From: <tel : +l-212-5555-llll> ; tag=171828 

To: <sip: domain.xferOcccfl .homel .net> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 

c=8642; port-s=7531 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



5. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities respond to the VCC UE with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

6. Evaluation of filter criteria 

In this example, and by evaluation of the initial filter criteria, based on the IMRN in the Request-URI header of 
the originating request for a registered VCC user, the S-CSCF routes the request to the VCC application. 

7. SIP INVITE request (intermediate IM CN subsystem entities to VCC application) - see example in 
table A.6-7 

The SIP INVITE request is forwarded from S-CSCF#1 in the home network to the VCC application which is at 
an AS. The AS acts as a routeing B2BUA. 
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Table A.6.2-7: SIP INVITE request (intermediate IM CN subsystem entities to VCC application) 



INVITE sip: domain.xfer@cccfl.homel.net SIP/2.0 



Via 
Via 
Via 



SIP/2 .0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1 



SIP/2 .0/UDP pcscfl.homel.net;branch=z9hG4bK24 0f34 .1 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net ; lr> 
Route: <sip: domain.xferOcccfl .homel .net> 
P-Asserted-Identity: <tel: +l-212-555-llll> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=type 

3homel .net ; 
P-Charging-Funtion-Address : CCf=[5555: :b99:c88:d77:e66] ; ccf=[5555: :a5 5:b44:c33:d22] ; 

ecf= [5555 : :lff :2ee:3dd:4cc] ; ecf= [5555 : : 6aa : 7bb : 8cc : 9dd] 
P-Access-Network-Info: IEEE-WLAN-802 . lib; 
Privacy: none 

From: < tel: +l-212-5555-llll>; tag=171828 
To: <sip: domain.xferOcccfl .homel .net> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 
Supported: precondition, lOOrel 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



8-9. SIP relNVITE request (VCC application to remote end) - see example in table A.6.2-7 

The remote end is informed of the change in access leg from CS domain to IM CN subsystem by sending a SIP 
relNVITE request from the VCC application to the remote end via the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.6.2-8: SIP relNVITE request (VCC application to remote end via intermediate IM CN 

subsystem entities) 



INVITE <sip: [5555: :eee:fff :aaa:bbb] :8805 SIP/2.0 

Via: SIP/2 . 0/UDP domain. xferocccfl.homel .net ;branch=z9hG4bK3 32b2 3 . 1 

Max-Forwards: 67 

Route: <sip : scscf .homel .net ; lr> 

P-Asserted- Identity: <tel:+l-212-555-llll> 

P-Access-Network-Info: IEEE-WLAN-802 . lib; 

Privacy: none 

From: < tel: +l-212-5555-llll>; tag=171828 

To: <sip: user2_publicl@home2 .net>; tag=1234 

Call -ID: dcl4bltlOb3teghmlk5 01444 

Cseq: 127 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : [7777 : : eee : ddd : ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



10-11. SIP 183 (Session Progress) response (remote end to intermediate IM CN subsystem entities) - see 
example in table A.6.2-10 

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the 
IP-CAN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC 
imposes no restriction on this operation. 
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Table A.6.2-10: SIP 183 (Session Progress) response (remote end to intermediate IM CN subsystem 

entities) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net : 5088 ;comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764zB7 . 1 , SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bKB71yl2 .1, SIP/2 .0/UDP 

scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip ipcscf 2 . visited2 .net : 50 8 8 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net ; lr> 
P-Asserted- Identity : <sip :user2_publicl@home2 .net> 
P-Access-Network-Info: IEEE-WLAN-802 . lib; 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term-ioi=home2 .net 
Privacy: none 
From: 
To: 

Call-ID: 
CSeq: 

Require: lOOrel, 
Supported: precondition 

Contact : <sip:[5555::eee:fff: aaa :bbb] : 8805 ; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: eee : fff : aaa :bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



12. SIP 183 (Session Progress) response (VCC application to intermediate IM CN subsystem entities) 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

The 183 (Session Progress) response is forwarded to the VCC UE indicating the supported media at the VCC 
application so that the VCC UE can start to reserve resources for IP bearer setup. 

13. SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to VCC UE) 

14 - 17. SIP PRACK request 

The SIP PRACK request does not carry SDP as the final codec decision is already made as part of the initial 
offer/answer exchange. 

18-19. SIP 200 (OK) response (remote end to VCC application via intermediate IM CN subsystem entities) 

The remote end acknowledges receipt of the SIP PRACK request by sending a SIP 200 (OK) response to the 
VCC appHcation via the originating IM CN subsystem (S-CSCF#1). 

12-21. SIP 200 (OK) response (VCC application to VCC UE) 

Final acknowledgement of receipt of the SIP PRACK request. 

22. SIP 200 (OK) response (remote end to intermediate IM CN subsystem entities) 
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The remote end acknowledges receipt of the SIP relNVITE request by sending a SIP 200 (OK) response to the 
intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

23. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the VCC application. 
There is no VCC specific content to this response. 

24. SIP ACK request (VCC application to intermediate IM CN subsystem entities) 

The SIP ACK request is sent from the VCC application to the intermediate IM CN subsystem entities thus 
completing session update for the remote leg. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

25. SIP ACK request (intermediate IM CN subsystem entities to remote end) 

The SIP ACK request is forwarded to the remote end via the intermediate IM CN subsystem entities thus 
completing session update for the remote leg. 

There is no VCC specific content to this response. 

26. SIP 200 (OK) response (VCC application to intermediate IM CN subsystem entities) 

Final acknowledgement of receipt of the SIP INVITE request required to change the access leg. This SIP 200 
(OK) response indicates successful receipt and processing of the SIP INVITE request which was sent to initiate 
domain transfer. This response is sent to the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC UE) 

Final acknowledgement of receipt of the SIP INVITE request required to change the access leg. This SIP 200 
(OK) response indicates successful receipt and processing of the SIP INVITE request which was sent to initiate 
domain transfer. The intermediate IM CN subsystem entities forwarded this response to the VCC UE. 

There is no VCC specific content to this response. 

28. SIP ACK request (VCC UE to intermediate IM CN subsystem entities) 

The SIP ACK request is sent from the VCC UE to the intermediate IM CN subsystem entities thus completing 
session setup for the updated access leg. 

There is no VCC specific content to this request. 

29. SIP ACK request (intermediate IM CN subsystem entities to VCC application) 

The SIP ACK request is forwarded by the intermediate IM CN subsystem entities to the VCC application thus 
completing session setup for the updated access leg. 

There is no VCC specific content to this request. 

30. IP bearer 

IP bearer is established between VCC UE and remote end allowing voice call to continue via PS domain. 

3 1 . SIP BYE request (VCC application to intermediate IM CN subsystem entities) 
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In order to release the access leg on the transferring-out access leg, the SIP BYE request is sent from the VCC 
application, via the intermediate IM CN subsystem entities. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

32. SIP BYE request (intermediate IM CN subsystem entities to MGCF) 

The SIP BYE request is forwarded to the MGCF by the intermediate IM CN subsystem entities in order to 
initiate call release in the CS domain. 

There is no VCC specific content to this request. 

33. ISUP REL message (MGCF to VMSC) 

MGCF converts SIP BYE request to an ISUP REL message sent to the MSC#1 in the home CS network. REL 
Cause Value No. 16 (Normal clearing) is used. 

34. ISUP RLC message (VMSC to MGCF) 

The RLC message is sent by MSC#1 to the MGCF in response to the REL message. 

35. DISCONNECT message (VMSC to VCC UE) 

The DISCONNECT message from MSC#1 to the VCC UE includes Cause Value No. 16, thus initiating call 
clearing. 

36. RELEASE message (VCC UE to VMSC) 

The VCC UE responds to the DISCONNECT message by sending the RELEASE message to MSC#1 and enters 
the 'release request' status. 

37. RELEASE COMPLETE message (VMSC to VCC UE) 

MSC#1 sends the RELEASE COMPLETE message to the VCC UE thus releasing the MM connection. 

38. SIP 200 (OK) response (MGCF to intermediate IM CN subsystem entities) 

This SIP 200 (OK) response is for the SIP BYE request and is sent to the intermediate IM CN subsystem entities 
from the MGCF. 

There is no VCC specific content to this response. 

39. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC application) 

This SIP 200 (OK) response is for the SIP BYE request and is forwarded to the VCC application by the 
intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

A. 6. 3 Signalling flows for unsuccessful CS domain to IIVI CN 
subsystem transfer 

Figure A.6.3-1 shows the signalling flows for the unsuccessful call transfer when transferring the call from the CS 
domain to the IM CN subsystem. The assumption is that VCC UE is not roaming and the MGCF is in the subscriber"s 
IM CN subsystem. It is also assumed that VCC UE is already registered to IM CN subsystem network. 
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Figure A.6.3-1 : Unsuccessful scenario when transferring call from CS to IM CN subsystem 

The details of the signalling flows are as follows: 
Step 1 through 7 are according to subclause A.6.2. 

8. VCC application 

When VCC application receives IMRN indicating the domain transfer, it does not recognize the call leg 
associated with Calling Party Number CgPN or P-Asserted-Identity. 

9. SIP 480 (Temporarily Unavailable) response (VCC application to intermediate IM CN subsystem entities) ■ 

see example in table A.6.3-9 

VCC application sends a SIP 480 (Temporarily Unavailable) response to the intermediate IM CN subsystem 
entities. 

Table A.6.3-9: SIP 480 (Temporarily Unavailable) response (VCC application to intermediate IM CN 

subsystem entities) 



SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK354216 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net : 7531;comp=sigcomp;branch=z9hG4bK240f 34 . 1, SIP/2 . 0/UDP 

[5555: : aaa : bbb : ccc : ddd] ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net : 7531 ; Ir; comp=sigcomp> 
P -Asserted- Identity: < sip: domain. xferOcccfl .homel .net> 
Privacy: none 

From: <tel:+l-212-555-llll>;tag=17182 8 
To: < sip: domain. xferOcccfl .homel .net>; tag=12 34 
Call -ID: Cb03a0s09a2sdfglkj4 90333 
Cseq: 12 7 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] > 
Content -Length: 



10. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to VCC UE) - see 
example in table A.6.3-10 

The error message is forwarded from intermediate IM CN subsystem entities to VCC UE according to standard 
procedures. 
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Table A.6.3-10: SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities 

to VCC UE) 



SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip:pcscf 1 . visitedl .net : 7531 ; Ir; comp=sigcomp> 

P-Asserted-Identity : <sip:domain.xfer(acccfl .homel .net > 

Privacy: none 

From: <tel:+l-212-555-llll>;tag=17182 8 

To: < sip: domain. xferOcccfl .homel .net>; tag=12 34 

Call -ID: Cb03a0s09a2sdfglk;j 490333 

Cseq: 12 7 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] > 

Content -Length: 



1 1 . VCC UE continues the call in CS domain. 



A.7 Signalling flows for IM CN subsystem to CS domain 
transfer 

A.7.1 Introduction 

The signalling flows for IM CN subsystem to CS domain transfer demonstrate how a VCC UE transfers the call from 
the IM CN subsystem to the CS domain. The following signalling flows are included: 

subclause A.7. 2 shows the successful transfer for a call, currently in the IM CN subsystem, and which is 
transferred to the CS domain; and 

subclause A.7. 3 shows the case where a transfer request for a call, currently in the IM CN subsystem, cannot be 
complied with at the VCC application due to the failure to match the request with an anchored call for that user. 

subclause A.7. 4 shows a domain transfer request from the IM CN subsystem to the CS domain using CAMEL, 
and which is rejected by the VCC application at the VMSC. 

A. 7. 2 Signalling flows for IM CN subsystem to CS domain transfer 

Figure A.7. 2-1 shows an example signalling flows for the domain transfer from the IM CN subsystem to the CS 
domain. The figure assumes that the UE is already registered with the CS domain prior to the decision to initiate 
transfer and that a call is anchored in the IM CN subsystem and the remote UE can be an IM UE. 

In this example, the communication between the CS domain and the VCC application to resolve and process the request 
for domain transfer is supported through CAMEL. 
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Figure A.7.2-1 : IM CN subsystem to CS domain transfer 

The details of the signalling flows are as follows: 

There is an ongoing IP bearer between the VCC UE and the remote end. 

1 . Determination of Domain Transfer to CS domain 

VCC UE can make a decision for domain transfer. It can be triggered in case that the access technology of VCC 
UE is changed or the user preference or the operator policy is changed in consequence of the access technology 
change and so on. 

2. CC SETUP messages (VCC UE to MSC) 

The VCC UE sends the CS SETUP message towards MSC with the VDN as the called party number. 

NOTE 1 : VDN (VCC Domain Transfer Number) is not a routeable number towards the VCC application. It is an 
MSISDN used by the UE to request a domain transfer towards the VCC application. 

3. CAMEL INITIAL DP (VMSC to gsmSCF) 
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On receipt of the SETUP message, the VMSC, in this example signalling flow, triggers a CAMEL activity 
which results in sending a CAMEL IDP message to the gsmSCF. The CAMEL IDF message contains at least: 

- the IMSI ie. 004412345678 

the calling party number ie. 12125551111; 

- the called party number that of the VDN, ie. 12415555555 

4. Handling of request for domain transfer 

The gsmSCF channels the request for domain transfer to the VCC Application. In this example, the VCC 
application accepts the request for domain transfer and assigns an IMRN, (IMRN = 12415553333). 

NOTE 2: The gsmSCF and the VCC application is connected through an unspecified interface left to vendor 
implementation. 

5. CAMEL CONNECT (gsmSCF to VMSC) 

Having made the decision to proceed with domain transfer, the VCC application causes the gsmSCF to respond 
to the CAMEL IDP message with a CAMEL CONNECT message containing: 

- the IMRN = 12415553333 

6. CC CALL PROCEEDING message (VMSC to VCC UE) 

As VMSC can now proceed with the call, VMSC indicates the CALL PROCEEDING message back to the UE. 

7. ISUP lAM (VMSC to MGCP) 

The VMSC initiates the CS call towards the MGCF by sending the lAM with the called party number (i.e. 
IMRN) to indicate the VCC application. 

NOTE 3: The IMRN is a routeable MSISDN number towards the VCC application. 

8. MGCF allocates and configures MGW 

MGCF retrieves SDP from the ISUP lAM according to the 3GPP TS 29.163 [10]. The MGCF communicates 
with the IM-MGW to configure the media bearer. 

9. SIP INVITE request (MGCF to the intermediate IM CN subsystem entities) - see example in table A.7.2-9 

The MGCF initiates a SIP INVITE request towards the I-CSCF in the home IM CN subsystem of the originating 
VCC user with the PSI of the VCC application as the called party number. The tel-URI format of the IMRN as a 
PSI (i.e. VCC application PSI) can be used for routeing towards the VCC application in the IM CN subsystem. I- 
CSCF routes the SIP INVITE request based on one of the standard procedures specified in "PSI based 
Application Server termination - direct/indirect/DNS routeing/service logic" procedures in 3GPP TS 23.228 [4]. 

The MGCF initiates a SIP INVITE request, containing an initial SDP. 3GPP TS 29.163 [10] specifies the 
principles of interworking between the 3GPP IM CN subsystem and ISUP based CS network, in order to support 
IM voice calls. 
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Table A.7.2-9: SIP INVITE request (MGCF to the intermediate IM CN subsystem entities) 



INVITE tel: +1-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bk731b87 

Max- Forwards : 7 

Route : <sip : icscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Access-Network-Info: IEEE-WLAN-802 . 11b; 

Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 

To: <tel: +l-241-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb :xxx;yyy 

s = - 

c=IN IP6 5555 :: aaa :bbb :xxx;yyy 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



Request-URI: Contains the VCC application PSI , as a PSI based on the IMRN obtained from CS network 
signalling. The VCC application PSI is equivalent to the tel-URI format of the IMRN. 

From: Contains the calling party number to indicate the CS part of the caller, (e.g. Tel: +1-1-212-555- 

1111). 

To: Contains the VCC application PSI as the destination address. The actual destination address used 

for domain transfer from IM CN subsystem to CS domain is kept in the VCC application by the 
CS originating procedures described in subclause 7 and subclause A.4. 

10. SIP INVITE request (intermediate IM CN subsystem entities to the VCC application) - see example in 
table A.7.2-10 

The IM CN subsystem entities route the SIP INVITE request towards the VCC application based on the VCC 
application PSI. 
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Table A.7.2-10: SIP INVITE request (intermediate IM CN subsystem entities to the VCC application) 



INVITE tel: +1-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK764z87, 

SIP/2 . 0/UDP icscfl.homel.net;branch=z9hG4bK332b23 .1, 

SIP/2 . 0/UDP mgcfl.homel.net;branch=z9hG4bk731b87 

Max-Forwards: 68 

Route: <sip : as .homel .net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Charging-Vector : icid-value= ' AyretyU0dm+601IrT5tAFrbHLso=023551024 ' ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 

To: <tel: +l-241-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb :xxx,-yyy 

s = - 

c = IN IP6 5555 :: aaa :bbb :xxx,-yyy 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



1 1 . VCC application initiates domain transfer 

The VCC application acts as a routeing B2BUA. In this example, the he VCC application correlates the IMRN 
with the info from the Initial DP procedure and retrieves the original called party number associated with the 
calling party number. 

NOTE 4: During the initial IM CN subsystem origination procedure, the VCC application will keep the called party 
number and the calling party number for anchoring, domain transfer and so on. 

12-13. SIP relNVITE request (VCC application to the remote UE through the intermediate IM CN subsystem 
entities) - see example in table A.7.2-12 

The VCC application forwards the SIP relNVITE request back to the S-CSCF. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.7.2-12: SIP relNVITE request (VCC application to the remote UE through the intermediate IM 

CN subsystem entities) 



INVITE sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2.0/UDP;branch=z9hG4bK764z8 7, 

Max- Forwards : 67 

Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Charging-Vector : icid-value= ' AyretyU0dm+601IrT5tAFrbHLso=023551024 ' ; orig-ioi=homel .net 

Privacy: none 

From: <tel:+l-212-555-llll>;tag=17182 8 

To : <sip :user2_public2@home2 .net>; tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj 590123 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact : <sip : [7777 : : eee : ddd : ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb :xxx;yyy 

s = - 

c=IN IP6 5555 :: aaa :bbb :xxx;yyy 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxpt ime : 2 



Request-URI: Contains the SIP-URI represented as an IP address indicating the called party UE, as retrieved 
from the VCC application. 

From: Contains the tel-URI indicating the remote VCC UE-A. A tag has same value in the existing 

dialog. 

To: Contains the SIP-URI of the called party UE. 

NOTE 5: If the called party UE is also the VCC UE, To header will be a tel-URI. 

Contact: Contains the SIP-URI indicating the VCC application. 

14-15. SIP 200 (OK) response (Remote UE to the VCC application through the intermediate IM CN 
subsystem entities) 

Indicate the successful completion of the SIP relNVITE request. 

There is no VCC specific content to this response. 

16-17. SIP ACK request (VCC application to the remote UE through the intermediate IM CN subsystem 
entities) 

There is no VCC specific content to this request. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

18-19. SIP 200 (OK) response (VCC application to the MGCP through the intermediate IM CN subsystem 
entities) 

Indicate the successful completion of the SIP INVITE request generated by the MGCF. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

20. ISUP ANM (MGCF to VMSC) 
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21. CC CONNECT message (VMSC to the CS part of UE-A) 

22. CC CONNECT ACK message (CS part of UE-A to the VMSC) 

23-24. SIP ACK request (MGCP to the VCC application through the IM CN subsystem entities) 

There is no VCC specific content to this request. 

25-26. SIP BYE request (VCC application to the IM part of UE-A through the IM CN subsystem entities) 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

27-28. SIP 200 (OK) response (IM part of UE-A to the VCC application through the intermediate IM CN 
subsystem entities) 

Indicate the successful completion of the SIP BYE request. 

There is no VCC specific content to this response. 

A. 7. 3 Signalling flows for unsuccessful IIVI CN subsystem to CS 
domain transfer 

Figure A.7.3-1 shows the signalling flows for the unsuccessful call transfer when transferring the call from the IM CN 
subsystem to the CS domain. The assumption is that VCC UE is not roaming and the MGCF is in the subscriber"s IM 
CN subsystem. 
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Figure A.7.3-1 : unsuccessful call transfer when transferring call from IM CN subsystem to CS domain 

The details of the signalHng flows are as follows: 

Step 1 through 10 are according to subclause A. 7. 2. 

11. VCC application 

When VCC application receives IMRN indicating the domain transfer, it does not recognize the call leg 
associated with Calling Party Number CgPN or P-Asserted-Identity. 

12. SIP 480 (Temporarily Unavailable) response (VCC application to intermediate IM CN subsystem entities) 
- see example in table A.7.3-12 

VCC application sends a SIP 480 (Temporarily Unavailable) response to the intermediate IM CN subsystem 
entities. 
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Table A.7.3-12: 480 (Temporarily Unavailable) response (VCC application to intermediate IIVI CN 

subsystem entities) 



SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK35421G . 1 , SIP/2. 0/UDP 

icscfl.homel.net;branch=z9hG4bK24 0f34 .1, SIP/2 . 0/UDP 

mgcf 1 .homel. net ;branch=z9hG4bk731b87 
Record- Route : <sip:scscfl .homel .net ; lr> 
P-Asserted- Identity: <tel : +l-212-555-llll> 
Privacy: none 

From: <sip:mgcfl .homel .net>; tag=171828 
To: <tel:+l-241-555-3333 SIP/2. 0>, tag=1234 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] > 
Content -Length: 



13. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to MGCF) - see 
example in table A.7.3-13 

The error message is forwarded from intermediate IM CN subsystem entities to MGCF according to standard 
procedures. 

Table A.7.3-13: SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities 

to IVIGCF) 



SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP mgcf 1 .homel .net ;branch=z9hG4bk731b87 

Record- Route : <sip:scscfl .homel .net; lr> 

P-Asserted- Identity: <tel : +l-212-555-llll> 

Privacy: none 

From: <sip:mgcfl .homel .net>; tag=171828 

To: <sip:domain.xfer(acccfl .homel .net>, tag=1234 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 12 7 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] ; > 

Content -Length: 



14. ISUP REL (MGCF to VMSC) 

Upon unsuccessful call setup, MGCF sends REL to VMSC. 

15. ISUP RLC (VMSC to MGCF) 

VMSC sends RLC to MGCF to confirm the REL. 

16. CC DISCONNECT message (VMSC to VCC UE) 
VMSC sends the DISCONNECT message to VCC UE. 

17. CC RELEASE message (VCC UE to VMSC) 

VCC UE acknowledges the DISCONNECT message by sending RELEASE message to VMSC. 

18. CC RELEASE COMPLETE message (VMSC to VCC UE) 

VMSC sends a RELEASE COMPLETE message to VCC UE to confirm the RELEASE message. 
19 VCC UE continues the call in IM CN subsystem 
VCC UE continues the call in IM CN subsystem. 

A. 7. 4 Signalling flows with domain transfer rejection at VMSC 
(using CAMEL) 

Figure A.7.4-1 shows the domain transfer attempt from the IM CN subsystem to the CS domain using CAMEL, and 
which is rejected by the VCC application at the VMSC. The domain transfer request is then abandoned, and the IMS 
call for which the domain transfer has been requested continues in the IM CN subsystem. 
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The decision to execute the request from the VCC UE for a domain transfer is subject to operator poHcy. 

NOTE: For domain transfer, the use of CAMEL in the context of VCC is optional. In this example the VMSC 
supports and uses CAMEL service logic. 
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Figure A.7.4-1 : Domain transfer rejection at VIVISC (using CAIVIEL) 

The details of the signalling flows are as follows: 

Steps 1, 2 and 3 are identical to the steps 1, 2 and 3 from the example in subclause A.7.2. 

4. Domain transfer decision 

The VCC application rejects the domain transfer request from the VCC UE to the CS domain according to the 
operator policy. In this example the VDN is not a routeable number towards the IM CN subsystem and the VCC 
application failed to assign a new IMRN for this call i.e. insufficient IMRN. 

5. CAMEL RELEASE CALL (VCC application to VMSC) 

The VCC application causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL RELEASE 
CALL message. The CAMEL RELEASE CALL message contains a release cause number #63 'Service or option 
not available, unspecified'. 

6. 7 and 8. DISCONNECT, RELEASE and RELEASE COMPLETE (from and to the VCC UE) 

The VMSC release the call toward the VCC UE; steps 6 to 8 are identical to step 16 to 18 from subclause A.7.3. 
The cause used in the DISCONNECT is mapped from the CAMEL release cause received by the VMSC. 
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There is no specific cause for VCC in the DISCONNECT. 

The call in the IM CN subsystem for which the domain transfer has been requested continues unchanged in the IM 
CN subsystem. 
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Annex B (informative): 
Example of filter criteria 

B.1 Introduction 

This annex provides some examples of filter criterion in the S-CSCF within the user profile of a specific public user 
identity. This filter criterion triggers S-CSCF actions following initial filter criteria evaluation of a SIP request thus 
resulting in orderly invocation of application servers. These examples are meant to illustrate the placement of the 
application server fulfilling the role of domain transfer function in a chain of application servers invoked to service an 
IMS session. 



B.2 Example 1 - VCC subscriber IMS Originating 

This example illustrates the case of iPC evaluations for originating sessions in the IM CN subsyetem initiated by a VCC 
subscriber who has also subscribed to the Connected Line Presentation (COLP) service. Only the example portion of 
iFC related to origination of an IM session is provided. Other portions of iPCs for evaluations of other SIP methods 
leading to actions on other application servers - for instance, for 3rd party registration - are not illustrated in this by 
example. 

For this example the illustration of the iFC is provided in an illustrative tabular form. 

For this example, the public user identity is userl_publicI@homel.net where homel.net is the URI of the home 
network. 

In this example, the first initial filter criteria triggers the S-CSCF to route the initial SIP INVITE request to the domain 
transfer function of the VSS AS addressed with the public service identity sip:dtfas. vcc.homel.net. When the SIP 
INVITE request is then returned from that VCC AS, the next initial filter criteria evaluation will cause the S-CSCF to 
route a SIP INVITE request to a call service application server for the user subscribed COLP service where that 
application server is addressed with the public service identity sipxolp. ssas.homel.net. 

Table B.2.1 : 

Service Profile (Public Identity user1_public1@home1.net) 

Initial Filter Criteria 

Priority 

Service Point Trigger 1 

Method: INVITE 

Session Case: Originating 

Application server: sip:dtfas.vcc.home1.net 

Initial Filter Criteria 

Priority 1 

Service Point Trigger 2 

Method: INVITE 

Session Case: Originating 

Application server: sip:Golp.ssas. home1.net 



B.3 Example 2 - VCC subscriber, IMS Terminating 

This example illustrates the case of iFC evaluations for a terminating session in the IM CN subsystem to a VCC 
subscriber who has also subscribed to OIP (Originating Identification Presentation) service. Only the example portion 
of iFC related to termination of an IM session is provided. Other portions of iFCs for evaluations of other SIP methods 
leading to actions on other application servers - for instance, for 3rd party registration - are not illustrated in this by 
example. 
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The provided example iFC illustrates only one method of populating the iFCs whereby the domain transfer function and 
the domain selection function are treated by separate application servers. This example does not preclude alternate 
means of invoking the domain selection function, for instance, within the processing of the domain transfer function 
itself. 

Editor's note: Might it be useful to illustrate other examples of invoking the domain transfer and domain selection 
functions to reflect alternatives as provided in stage 2? That would however, require a separate annex of 
examples showing the use of filter criteria to invoke application servers in their required order. 

For this example the illustration of the iFC is provided in XML form. 

For this example, the terminating user has the public user identity user2_public2@home2.net where the home2.net is 
the URI of the home network. 

In this example, this 1st initial Filter Criteria evaluation causes the S-CSCF to route a SIP INVITE request to an 
application server treating the user's subscribed call related service. In this example, the user's subscribed services are 
Call Diversion services and OIP service. This call service application server, in this example, is addressed with the 
pubUc service identity sipxallserv. ssas.home2.net. 

When a SIP INVITE request is returns from the call services application server the next initial Filter Criteria evaluation 
will cause the S-CSCF to route a SIP INVITE request to an AS which performs the role of Domain Transfer Function of 
a VCC application addressed with the public service identity sip:dtfas. vcc.home2.net. After the anchor decision has 
been taken and the VCC AS with the domain transfer function role returns a SIP INVITE request, wherein the next iFC 
evaluation leads the S-CSCF to route a SIP INVITE request to an AS which performs the role of domain selection 
function addressed with the public service identity sip:dsfas. vcc.home2.net. 

<ServiceProf ile> 

<PublicIdentity> 

<Identity> sip :user2_public2®home2 .net </Identity> 
</PublicIdentity> 
<InitialFilterCriteria> 

<Priority>0</Priority> 
<TriggerPoint> 

<ConditionTypeCNF>0</ConditionTypeCNF> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > </ Group > 
<Method>INVITE</Method> 

</SPT> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > < / Group > 
<SessionCase>l</SessionCase> 

</SPT> 
</TriggerPoint> 
<ApplicationServer> 

<ServerName>sip : callserv . ssas . home2 . net </ServerName> 
<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</InitialFilterCriteria> 
<InitialFilterCriteria> 

<Priority>10</Priority> 
<TriggerPoint> 

<ConditionTypeCNF>0</ConditionTypeCNF> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > </ Group > 
<Method>INVITE</Method> 

</SPT> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > </ Group > 
<SessionCase>l</SessionCase> 

</SPT> 
</TriggerPoint> 
<ApplicationServer> 

<ServerName>sip :dtf as . vcc .home2 .net </ServerName> 

<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</InitialFilterCriteria> 
<InitialFilterCriteria> 

<Priority>10 0</Priority> 
<TriggerPoint> 
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<ConditionTypeCNF>0</ConditionTypeCNF> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 
<Group>0</Group> 
<Method>INVITE</Method> 
</SPT> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 
< Group > </ Group > 
<SessionCase>l</SessionCase> 
</SPT> 
</TriggerPoint> 
<ApplicationServer> 

<ServerName>sip :dsf as . vcc .home2 .net </ServerName> 
<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</InitialFilterCriteria> 
</ServiceProf ile> 
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